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
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
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/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
AW: AW: [OT] Getting TLS handshake details
> -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/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
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/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/bouncycastle/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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: [OT] Getting TLS handshake details
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/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/bouncycastle/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. Greetings, Thomas
