Thomas,
On 4/15/22 14:11, Thomas Hoffmann (Speed4Trade GmbH) wrote:
-----Ursprüngliche Nachricht-----
Von: Christopher Schultz <ch...@christopherschultz.net>
Gesendet: Freitag, 15. April 2022 19:21
An: users@tomcat.apache.org
Betreff: Re: AW: [OT] Getting TLS handshake details
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/bo
uncycastle/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
Hello Chris,
I found a tutorial about writing crypto providers:
https://docs.oracle.com/javase/9/security/howtoimplaprovider.htm#JSSEC-GUID-7C304A79-6D0B-438B-A02E-51648C909876
Despite I never wrote one, it should be possible to wrap the classes and
register own crypto providers.
Maybe BouncyCastle is a possible starting point.
As TLS-algorithms consists of several parts (signature, padding, encryption,
decryption, key exchange, ...) it might be a bit tedious.
Another option would be to fork e.g. BouncyCastle and add some debug-outputs or
public methods to reach out the needed information.
One of my goals for this project[1] was not to use anything outside of
the platform's JRE.
-chris
[1] https://github.com/ChristopherSchultz/ssltest
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
