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?
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