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/cla > > >>> ss es /com/sun/crypto/provider/DHKeyAgreement.java > > >>> > > >>> BouncyCastle has a similar class: > > >>> https://github.com/bcgit/bc-java/blob/master/core/src/main/java/or > > >>> g/ 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
Just another solution came into my mind. When using a Java agent, you can influence the classloading and replace a class with your own class which has additional logging information. An example is given here: https://stackoverflow.com/questions/35424320/how-do-i-replace-a-class-with-new-one-with-java-instrumentation Thus you might not have to wrap all depending classes. Maybe you can store the relevant information within an MDC, variable, ThreadLocal variable etc. in order to fetch it later on (maybe with reflection). On stackoverflow they also mention the endorsed mechanism but I never got deeper into that topic. Greetings, Thomas
