Hello Chris, > -----Ursprüngliche Nachricht----- > Von: Christopher Schultz <ch...@christopherschultz.net> > Gesendet: Freitag, 15. April 2022 21:28 > An: users@tomcat.apache.org > Betreff: Re: AW: AW: [OT] Getting TLS handshake details > > 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/class > >>> es /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 >
Of course you can also use the JDK-classes and write your wrapper around. BouncyCastle only shows, that its possible to add custom cipher providers. Maybe you can wrap the JDK-classes and peek at BC, if it helps to gain some insights or inspiration. Greetings, Thomas
