Thomas,
On 4/15/22 02:25, Thomas Hoffmann (Speed4Trade GmbH) wrote:
Hello Chris,
-----Ursprüngliche Nachricht-----
Von: Christopher Schultz <ch...@christopherschultz.net>
Gesendet: Donnerstag, 14. April 2022 23:15
An: users@tomcat.apache.org
Betreff: Re: [OT] Getting TLS handshake details
Peter,
On 4/14/22 03:45, Peter Kreuser wrote:
Chris,
Am 13.04.2022 um 21:37 schrieb Christopher Schultz
<ch...@christopherschultz.net>:
All,
I asked this question a few years ago on SO and I didn't really get an
answer:
https://stackoverflow.com/questions/39374024/determine-diffie-
hellman
-parameters-length-for-a-tls-handshake-in-java
Does anyone know if it's possible to get the DHE key-exchange
parameters during the TLS handshake using just SSLSocket on the client end?
I'm trying to detect when the server is using "weak" DH key lengths like <=
1024 bits.
(I'm also curious as to why my ssltest tool[1] is unable to connect
to a server which is allowing ADH-AES128-GCM-SHA256 aka
TLS_DH_anon_WITH_AES_128_GCM_SHA256 ; I suspect it has something
to
do with my JVMs unwillingness to use 1024-bit DHE for the handshake,
and I can't figure out how to turn it off. SSLLabs and sslscan both
report this cipher suite as being "enabled" on the server, but my
tool reports that the handshake failed, which usually implies that
the cipher suite is disabled.)
Is your question how to detect this in code? Or specifically in Java?
Specifically in Java, and without any cooperation from the server e.g.
returning the details in some kind of HTTP header. I expect to perform a TLS
handshake only and then terminate the socket connection.
Anyways Do you know testssl.sh?
I think that just executes openssl in a loop, no?
If I want to know how to handle a specific tls problem I check in
Dirk's code and start from there...
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
I think the DH params are hidden quite deeply within the crypto classes.
JDK-Implementation is e.g. within the class:
https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/com/sun/crypto/provider/DHKeyAgreement.java
BouncyCastle has a similar class:
https://github.com/bcgit/bc-java/blob/master/core/src/main/java/org/bouncycastle/crypto/agreement/DHAgreement.java
Maybe the only way would be to debug into the classes, use java.net.debug or
provide an own crypto provider which will reveal the params.
Now, that's an interesting possibility. I wonder if it would be possible
to implement a cryptographic provider that simply passes-through all
calls to the default provider, but is able to observe some of these
interesting details.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
