2

I've got a Dropwizard application where a resource needs to invoke a resource on another Dropwizard application. We noticed that a lot of time is spent on SSL renegotiation. Upon closer inspection this happens only if the other application is on the same machine. I.e:

client.target("https://mymachine.com/test").request().post(null);
client.target("https://mymachine.com/test").request().post(null);
// renegotiation

if using command line option -Djavax.net.debug=ssl:handshake:verbose the log says

%% Client cached [Session-13, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
%% Try resuming [Session-13, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256] from port 55043
...
%% Invalidated:  [Session-13, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
%% Initialized:  [Session-15, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]

But when invoking the same service on my local machine: 

client.target("https://othermachine.com/test").request().post(null);
client.target("https://othermachine.com/test").request().post(null);
// SSL session re-use (=wanted)

The log says:

%% Client cached [Session-15, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]
%% Try resuming [Session-15, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256] from port 55051
...
%% Server resumed [Session-15, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]

What is going on here?

Friso
  • 1,080
  • 6
  • 37
  • Have you noticed that the cyphers are different? `TLS_ECDHE_RSA_WITH_AES_128_` **CBC** `_SHA256` vs `TLS_ECDHE_RSA_WITH_AES_128_` **GCM** `_SHA256` – zloster Oct 07 '18 at 07:01
  • So there is some difference in the way TLS is negotiated and the `CBC` implementation is NOT supporting `resumption`. You have some digging to do. – zloster Oct 07 '18 at 07:04

1 Answers1

3

Turns out the java versions differed. My localhost was using an old version :-$ .

Java™ SE Development Kit 8, Update 161 (JDK 8u161) January 16, 2018

New Features

security-libs/javax.net.ssl Added TLS session hash and extended master secret extension support Support has been added for the TLS session hash and extended master secret extension (RFC 7627) in JDK JSSE provider. Note that in general, server certificate change is restricted if endpoint identification is not enabled and the previous handshake is a session-resumption abbreviated initial handshake, unless the identities represented by both certificates can be regarded as the same. However, if the extension is enabled or negotiated, the server certificate changing restriction is not necessary and will be discarded accordingly. In case of compatibility issues, an application may disable negotiation of this extension by setting the System Property jdk.tls.useExtendedMasterSecret to false in the JDK. By setting the System Property jdk.tls.allowLegacyResumption to false, an application can reject abbreviated handshaking when the session hash and extended master secret extension is not negotiated. By setting the System Property jdk.tls.allowLegacyMasterSecret to false, an application can reject connections that do not support the session hash and extended master secret extension.

See JDK-8148421

Friso
  • 1,080
  • 6
  • 37
  • We had the same problem. Note that to reproduce this you must have two Java appliactions directly communicating to each other (i.e. no reverse proxy like Apache or nginx). The first app must be older than JDK 8u161 and the latter must be JDK 8u161+. – gargii Jun 04 '19 at 11:17