TLS handshake debug logging

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

TLS handshake debug logging

Erik Nellessen

smime.p7m (19K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TLS handshake debug logging

Peter Dettman-3
Hi Erik,
Yes, there is only a limited set of things logged at present. We are
happy to add more, but it's somewhat low priority from our point of
view. It will matter more for encrypted handshakes in TLS 1.3, since one
can use a tool like Wireshark to inspect handshakes in TLS 1.2 and earlier.

Perhaps you could open an issue at github (of course a PR is welcome
too) listing a smallish set of log messages that you need most urgently.
That's something we could likely get to quickly.

"debug log messages comparable to those of the SUN JSSE provider" is
something we can only approach incrementally because of the effort involved.

Regards,
Pete Dettman


On 29/6/20 4:37 pm, Erik Nellessen wrote:

> For testing purposes, we need to see every detail of the TLS handshake
> (i.e. especially all secrets). When using the SUN JSSE provider, we
> could do this by using the following command line parameter:
>
> "-Djavax.net.debug=ssl:handshake"
>
>  
>
> We then got log messages of all the details we needed. The log messages
> looked like this (shortened) example:
>
> 'javax.net.ssl|DEBUG|0C|nioEventLoopGroup-3-1|2020-06-29 07:34:50.874
> UTC|ClientHello.java:809|Consuming ClientHello handshake message (
> "ClientHello": {
>  "client version"      : "TLSv1.2",
>  "random"              : "3B 5B 15 D0 30 7F F7 60 87 74 91 CB 93 88 DE
> E0 BB 27 7D F5 F2 7A A9 69 C9 F6 32 18 93 4D 25 79",
>
> …'
>
>  
>
> Now we needed to add support for the EC brainpool curve. This could not
> be done via the SUN JSSE provider, but could be done with the
> BouncyCastle JSSE provider. So we switched to the BouncyCastle JSSE
> provider.
>
>  
>
> We now do not see any TLS debug logging messages anymore. When searching
> for logging configuration in the BouncyCastle JSSE provider, I found
> information stating that it integrates into the JRE logging. So I set
> the log level in my JRE to "FINEST" and tried again. But the only log
> messages I got were the following:
>
> 'Jun 29, 2020 9:01:30 AM org.bouncycastle.jsse.provider.PropertyUtils
> getIntegerSystemProperty
> FINE: Integer system property [jdk.tls.ephemeralDHKeySize] defaulted to:
> 2048
> Jun 29, 2020 9:01:30 AM org.bouncycastle.jsse.provider.ProvTlsServer
> processClientExtensions
> FINE: Server ignored SNI (no matchers specified)
> Jun 29, 2020 9:01:30 AM org.bouncycastle.jsse.provider.ProvTlsServer
> getServerVersion
> FINE: Server selected protocol version: TLSv1.2
> Jun 29, 2020 9:01:30 AM org.bouncycastle.jsse.provider.PropertyUtils
> getBooleanSystemProperty
> FINE: Boolean system property [org.bouncycastle.jsse.ec.disableChar2]
> defaulted to: false
> Jun 29, 2020 9:01:30 AM org.bouncycastle.jsse.provider.PropertyUtils
> getBooleanSystemProperty
> FINE: Boolean system property [org.bouncycastle.ec.disable_f2m]
> defaulted to: false
> Jun 29, 2020 9:01:30 AM org.bouncycastle.jsse.provider.ProvTlsServer
> getSelectedCipherSuite
> FINE: Server selected cipher suite:
> TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256'
>
>  
>
> I could not see any information about secrets, randoms, etc. All the
> information we need is missing.
>
>  
>
> Is there a way to configure logging in BouncyCastle so I can see TLS
> debug log messages comparable to those of the SUN JSSE provider? Any
> kind of help would be appreciated.
>
>  
>
> Kind regards,
>
> Erik
>


Reply | Threaded
Open this post in threaded view
|

Re: TLS handshake debug logging

Erik Nellessen
Hi Peter,

thanks for your reply. I can confirm that inspecting TLS 1.2 handshakes
with Wireshark is generally possible. Anyhow, this approach also has
some limitations. In our case, a Diffie-Hellman key exchange is
performed. As far as I know at the moment, Wireshark does not support
decrypting TLS channels with DHE yet (see
https://support.citrix.com/article/CTX116557). With the Wireshark
approach, you also cannot see intermediate data, e.g. the random number
(ephemeral private key) that is chosen to do the DHE.

Do you agree to this or am I missing something?

So from my point of view, the most important things to log are:
* The SSL session keys
* The ephemeral private keys

I will create an issue on github with these points (except I
misunderstood something and notice it before).

Kind regards,
Erik

On 29.06.20 14:28, Peter Dettman wrote:

> Hi Erik,
> Yes, there is only a limited set of things logged at present. We are
> happy to add more, but it's somewhat low priority from our point of
> view. It will matter more for encrypted handshakes in TLS 1.3, since one
> can use a tool like Wireshark to inspect handshakes in TLS 1.2 and earlier.
>
> Perhaps you could open an issue at github (of course a PR is welcome
> too) listing a smallish set of log messages that you need most urgently.
> That's something we could likely get to quickly.
>
> "debug log messages comparable to those of the SUN JSSE provider" is
> something we can only approach incrementally because of the effort involved.
>
> Regards,
> Pete Dettman
>
>
> On 29/6/20 4:37 pm, Erik Nellessen wrote:
>> For testing purposes, we need to see every detail of the TLS handshake
>> (i.e. especially all secrets). When using the SUN JSSE provider, we
>> could do this by using the following command line parameter:
>>
>> "-Djavax.net.debug=ssl:handshake"
>>
>>  
>>
>> We then got log messages of all the details we needed. The log messages
>> looked like this (shortened) example:
>>
>> 'javax.net.ssl|DEBUG|0C|nioEventLoopGroup-3-1|2020-06-29 07:34:50.874
>> UTC|ClientHello.java:809|Consuming ClientHello handshake message (
>> "ClientHello": {
>>  "client version"      : "TLSv1.2",
>>  "random"              : "3B 5B 15 D0 30 7F F7 60 87 74 91 CB 93 88 DE
>> E0 BB 27 7D F5 F2 7A A9 69 C9 F6 32 18 93 4D 25 79",
>>
>> …'
>>
>>  
>>
>> Now we needed to add support for the EC brainpool curve. This could not
>> be done via the SUN JSSE provider, but could be done with the
>> BouncyCastle JSSE provider. So we switched to the BouncyCastle JSSE
>> provider.
>>
>>  
>>
>> We now do not see any TLS debug logging messages anymore. When searching
>> for logging configuration in the BouncyCastle JSSE provider, I found
>> information stating that it integrates into the JRE logging. So I set
>> the log level in my JRE to "FINEST" and tried again. But the only log
>> messages I got were the following:
>>
>> 'Jun 29, 2020 9:01:30 AM org.bouncycastle.jsse.provider.PropertyUtils
>> getIntegerSystemProperty
>> FINE: Integer system property [jdk.tls.ephemeralDHKeySize] defaulted to:
>> 2048
>> Jun 29, 2020 9:01:30 AM org.bouncycastle.jsse.provider.ProvTlsServer
>> processClientExtensions
>> FINE: Server ignored SNI (no matchers specified)
>> Jun 29, 2020 9:01:30 AM org.bouncycastle.jsse.provider.ProvTlsServer
>> getServerVersion
>> FINE: Server selected protocol version: TLSv1.2
>> Jun 29, 2020 9:01:30 AM org.bouncycastle.jsse.provider.PropertyUtils
>> getBooleanSystemProperty
>> FINE: Boolean system property [org.bouncycastle.jsse.ec.disableChar2]
>> defaulted to: false
>> Jun 29, 2020 9:01:30 AM org.bouncycastle.jsse.provider.PropertyUtils
>> getBooleanSystemProperty
>> FINE: Boolean system property [org.bouncycastle.ec.disable_f2m]
>> defaulted to: false
>> Jun 29, 2020 9:01:30 AM org.bouncycastle.jsse.provider.ProvTlsServer
>> getSelectedCipherSuite
>> FINE: Server selected cipher suite:
>> TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256'
>>
>>  
>>
>> I could not see any information about secrets, randoms, etc. All the
>> information we need is missing.
>>
>>  
>>
>> Is there a way to configure logging in BouncyCastle so I can see TLS
>> debug log messages comparable to those of the SUN JSSE provider? Any
>> kind of help would be appreciated.
>>
>>  
>>
>> Kind regards,
>>
>> Erik
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: TLS handshake debug logging

Peter Dettman-3
Hi Erik,

Yes there's a whole class of internal data that is never sent on the
wire and therefore not visible in Wireshark, including of course private
keys and other secrets.

I will followup on the github issue once it's opened.

Regards,
Pete Dettman


On 29/6/20 10:07 pm, Erik Nellessen wrote:

> Hi Peter,
>
> thanks for your reply. I can confirm that inspecting TLS 1.2 handshakes
> with Wireshark is generally possible. Anyhow, this approach also has
> some limitations. In our case, a Diffie-Hellman key exchange is
> performed. As far as I know at the moment, Wireshark does not support
> decrypting TLS channels with DHE yet (see
> https://support.citrix.com/article/CTX116557). With the Wireshark
> approach, you also cannot see intermediate data, e.g. the random number
> (ephemeral private key) that is chosen to do the DHE.
>
> Do you agree to this or am I missing something?
>
> So from my point of view, the most important things to log are:
> * The SSL session keys
> * The ephemeral private keys
>
> I will create an issue on github with these points (except I
> misunderstood something and notice it before).
>
> Kind regards,
> Erik

Reply | Threaded
Open this post in threaded view
|

AW: [dev-crypto] TLS handshake debug logging

Erik Nellessen
Ok, so it seems I got this right. Thank you for the feedback. I created an issue on github: https://github.com/bcgit/bc-java/issues/742

Kind regards,
Erik

-----Ursprüngliche Nachricht-----
Von: Peter Dettman <[hidden email]>
Gesendet: Dienstag, 30. Juni 2020 07:45
An: [hidden email]
Betreff: Re: [dev-crypto] TLS handshake debug logging

Hi Erik,

Yes there's a whole class of internal data that is never sent on the
wire and therefore not visible in Wireshark, including of course private
keys and other secrets.

I will followup on the github issue once it's opened.

Regards,
Pete Dettman


On 29/6/20 10:07 pm, Erik Nellessen wrote:

> Hi Peter,
>
> thanks for your reply. I can confirm that inspecting TLS 1.2 handshakes
> with Wireshark is generally possible. Anyhow, this approach also has
> some limitations. In our case, a Diffie-Hellman key exchange is
> performed. As far as I know at the moment, Wireshark does not support
> decrypting TLS channels with DHE yet (see
> https://support.citrix.com/article/CTX116557). With the Wireshark
> approach, you also cannot see intermediate data, e.g. the random number
> (ephemeral private key) that is chosen to do the DHE.
>
> Do you agree to this or am I missing something?
>
> So from my point of view, the most important things to log are:
> * The SSL session keys
> * The ephemeral private keys
>
> I will create an issue on github with these points (except I
> misunderstood something and notice it before).
>
> Kind regards,
> Erik