> -----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. Greetings, Thomas
