AW: AW: AW: [OT] Getting TLS handshake details
Hello Chris, > > > -Ursprüngliche Nachricht- > > Von: Christopher Schultz > > 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 > > >> 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 > > 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 > > : > > >> > > >> 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. >
AW: AW: AW: [OT] Getting TLS handshake details
Hello Chris, > -Ursprüngliche Nachricht- > Von: Christopher Schultz > 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 > >> 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 > 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 > : > >> > >> 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
