SSL session resumption over TLS 1.3

Gatling (Open-Source)
1

We’re currently using Gatling 3.5.1 with OpenJDK 11. We want to understand why SSL session resumption over TLS 1.3 is not happening.

Our understanding is TLS 1.3 is fully supported in OpenJDK 11
https://bugs.openjdk.java.net/browse/JDK-8202625

But we do not see SSL sessions being resumed when Gatling performs SSL handshakes with our target server over TLS 1.3.

  • When we set root level to DEBUG in logback.xml, we see Gatling “TLS handshake successful” debug logs (DefaultHttpClient.java#L744) but without needed details.
  • When we enable debugging utility with -Djavax.net.debug=ssl, we do not see SSL handshake details for individual Gatling HTTP requests.

Is it possible to enable Gatling to send low level SSL handshake debug messages to console?

2
  1. Is session resumption really supposed to happen in your case? Keep in mind that unless you use shareConnections, each virtual user will have it’s own SSLContext.
  2. By default, Gatling uses BoringSSL, not JDK’s SSLEngine, so no surprise you don’t see -Djavax.net.debug=ssl logs. You can change that in frontline.conf.
3

frontline.conf => gatling.conf

4

Thank you much, Stéphane for insights and suggestions. I completely missed the OpenSSL/BoringSSL setting in gatling.conf.

After disabling OpenSSL/BoringSSL, I managed to collect low level Java debug logs of SSL handshake messages and observe session resumption behaviors in following combination:

5

I would need you to provide a sample server app demoing that SSLSessions are not resumed with BoringSSL so I can open a ticket against Netty.

Regards,

6

Could you please enforce TLSv1.2 with BoringSSL?

So I would expect stateful session resumption to properly work with BoringSSL with TLSv1.2

7

I can only use tcpdump to debug SSL handshake when BoringSSL is enabled.

When BoringSSL is enforced with TLSv1.2 and with/without Netty setting (-Dio.netty.handler.ssl.openssl.sessionCacheClient=true)

  • Session ID is always empty (length=0) in Client Hello → no stateful session resumption

  • There’s no SessionTicket TLS Extension in Client Hello either → no stateless session resumption
    When BoringSSL is run with TLSv1.3 and Netty setting

  • pre_shared_key Extension is never included in Client Hello → no PSK session resumption
    Other than these tcpdump trace logs, I do not have any debug logs to explain whether session resumption is not happening due to server (our app HAProxy) or client (Netty/BoringSSL).

Stéphane - if you’re convinced it’s a client (Netty/BoringSSL) issue, would tcpdump traces are sufficient for filing a ticket against Netty?

8

I’ve opened an issue against Netty: https://github.com/netty/netty/issues/11505