确定Diffie-Hellman“参数”。 Java中TLS握手的长度 [英] Determine Diffie-Hellman "Parameters" Length for a TLS handshake in Java

问题描述

我想与服务器建立HTTPS连接，如果我使用
非临时DH密钥交换，我想知道
对于该连接的参数是什么。实际上，我真的不在乎它是不是短暂的
。

I'd like to make an HTTPS connection to a server and, if I'm using non-ephemeral DH key exchange, I'd like to know what the parameters are for that connection. Actually, I don't really care if it's ephemeral or not.

我正在寻找的是能够建立连接然后警告
如果连接使用弱DH参数。这是我
可以在连接时检查的东西吗？或者是由密码套件本身
定义的DH参数集（或者更多
具体地，这些参数的长度）？

What I'm looking for is the ability to make a connection and then warn if the connection is using "weak" DH parameters. Is that something I can check at connection-time? Or is the set of DH parameters (or, more specifically, the length of those parameters, in bits) defined by the cipher suite itself?

例如，Qualys社区线程有一个SSLLabs认为弱的
密码套件的图示（好吧，每个人都认为
他们很弱......他们只是抱怨他们的公共工具）：
https://community.qualys.com/thread/ 14821

For example, the Qualys community thread has an illustration of the cipher suites that SSLLabs considers "weak" (well, everyone considers them weak... they just have a public tool which complains about them): https://community.qualys.com/thread/14821

他们特别提到例如 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
这是密码套件0x9f并提及DH参数。那些
参数的参数是否被加密到密码套件中（意味着它们是
总是 1024位）或者这是服务器的配置，使得
那些密码套件由于特定的DH参数选择而变弱？

They specifically mention e.g. TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 which is cipher suite 0x9f and mention the DH parameters. Are those parameters' parameters baked-into the cipher suite (meaning they are always 1024-bit) or is this a configuration of the server that makes those cipher suites weak due to the specific DH parameter choice?

在任何一种情况下，我都希望能够从
连接中嗅探该信息，如果在所有可能的。有谁知道这是否可以做到，
以及如何做？

In either case, I'd like to be able to sniff that information from the connection if at all possible. Does anyone know if this can be done, and how?

我写了一些代码来尝试获取有关握手的信息，但我保留为我希望包含此数据的对象获取 null 。

I've written some code to attempt to get this information about the handshake, but I keep getting null for the object I was hoping would contain this data.

SSLSocketFactory sf = ...;
Socket sock = new Socket();
sock.connect(address, timeout);

SSLSocket socket = (SSLSocket)sf.createSocket(sock, host, port, true);
socket.startHandshake();
SSLSession sess = socket.getHandshakeSession();

我希望此时 sess 将包含一些有关握手的有趣信息，但它是 null 。 startHandshake 的javadoc表示它将在握手完成时通知事件侦听器。所以我尝试了这个：

I was hoping that sess at this point would contain some interesting information about the handshake, but it's null. The javadoc for startHandshake indicates that it will notify an event listener when the handshake is completed. So I tried this:

SSLSocketFactory sf = ...;
Socket sock = new Socket();
sock.connect(address, timeout);

SSLSocket socket = (SSLSocket)sf.createSocket(sock, host, port, true);
socket.startHandshake();
// SSLSession sess = socket.getHandshakeSession();
SSLSession sess = socket.getSession(); // This forces the handshake to complete
sess = socket.getHandshakeSession();

...但 sess 仍然 null 此时。 真正的SSLSession确实存在，并提供有关连接的信息，但握手会话似乎总是 null 。

... but sess is still null at this point. The "real" SSLSession does exist and gives me information about the connection, but the "handshake session" seems to always be null.

所以我尝试写一个 HandshakeCompletedListener ，我确实得到一个 SSLSession ，但它出现了我已经可以从 SSLSocket 获得同样的一个，所以握手会话似乎没有用。

So I tried writing an HandshakeCompletedListener, and I do in fact get an SSLSession, but it appears to be the same one that I can get from the SSLSocket already, so the "handshake" session seems to be unhelpful.

如何从 SSLSession 获取这些参数？

推荐答案

这些参数的参数是否被加密到密码套件中（意味着它们总是1024位），或者这是服务器的配置，由于特定的DH参数选择，使得这些密码套件变弱了？

Are those parameters' parameters baked-into the cipher suite (meaning they are always 1024-bit) or is this a configuration of the server that makes those cipher suites weak due to the specific DH parameter choice?

不，这是协议的配置参数 。 Java的默认值为1024位，但可以使用系统属性为JSSE（Java TLS实现）更改全局： jdk.tls.ephemeralDHKeySize 。最好在启动期间使用Java VM的-D选项设置它。

No, this is a configuration parameter for the protocol. There is a default of 1024 bits for Java but that may be changed globally for JSSE (the Java TLS implementation) using a system property: jdk.tls.ephemeralDHKeySize. Best set this during startup with a -D option for the Java VM.

对于静态DH密钥对（用于身份验证），您必须查看DH证书。但我不认为你会找到任何人，每个人都使用RSA进行身份验证。

For static DH key pairs (that are used for authentication) you would have to look into the DH certificate. But I don't think you'll find any, everybody uses RSA for authentication.

在任何一种情况下，我都想成为如果可能的话，能够从连接中嗅出那些信息。有谁知道这是否可以做到，以及如何做？

In either case, I'd like to be able to sniff that information from the connection if at all possible. Does anyone know if this can be done, and how?

好吧，对于嗅探工具，如WireShark就够了毫无疑问，您可以解析TLS连接中的DH参数等问题（当然，如果它们首先使用的话）。

Well, for sniffing tools such as WireShark would suffice. Undoubtedly you can parse things like DH parameters from a TLS connection (if they are used in the first place of course).

您还可以使用 -Djavax.net.debug

You can also debug connections using -Djavax.net.debug

对于Java应用程序/库，您可以查找密码套件，然后，如果它包含 DHE_ 查找上述系统属性（记住它的默认值）。

For Java applications / libraries you could look up the cipher suite and then, if it contains DHE_ look up the aforementioned system property (keeping in mind its default values).

Java JSSE API并未考虑深度数据包检查。它（字面上）是服务器和客户端应用程序的面向服务的实现。虽然你当然可以使用OpenJDK代码本身（它是GPL的，对吗？）你最好使用单独的实现，可能还有更宽松的许可。

The Java JSSE API was not written with deep packet inspection in mind. It's (literally) a service oriented implementation for servers and client applications. Although you could of course use the OpenJDK code itself (it's GPL'ed, right?) you are better off using a separate implementation, possibly with an even more permissive license.

对于嗅探器，我宁愿使用C / C ++（或至少是C / C ++前端）而不是Java。

For a sniffer however I would rather use C/C++ (or at least a C/C++ frontend) than Java.

这篇关于确定Diffie-Hellman“参数”。 Java中TLS握手的长度的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！