Cannot disable SSL Session Caching

[haus]

Recently we added a setting to our application which allows ssl session caching to be configurable. We did this by calling setSessionCachingEnabled with false when creating the ssl context. This appears to have no effect on whether or not ssl sessions are cached. At a glance this appears similar to https://bugs.eclipse.org/bugs/show_bug.cgi?id=418892 but in reverse. While that bug was about caching not working when enabled, this issue is about it working even when disabled.

To reproduce:

1. grab latest jetty source
2. Make an xml file with the following contents (I called mine tweak-ssl.xml)

<Configure id="sslContextFactory" class="org.eclipse.jetty.util.ssl.SslContextFactory">
  <Set name="sessionCachingEnabled"><Property name="jetty.sslContext.sessionCachingEnabled" default="false"/></Set>
</Configure>

1. set jetty to run https java -jar start.jar --add-to-start=https
2. Add the above xml file to start.ini or load it using java -jar start.jar etc/tweak-ssl.xml
3. while jetty is running, call something like openssl s_client -reconnect -connect 127.0.0.1:8443 | grep Session-ID:

Expected:
A list of 6 different session IDs (1 for initial connect, 5 more for each reconnection).

Actual:

    Session-ID: 57155155278F5A3C4C8CD8E887CC2FF49A582C9912AD4926B64916B1F63B9880
    Session-ID: 57155155278F5A3C4C8CD8E887CC2FF49A582C9912AD4926B64916B1F63B9880
    Session-ID: 57155155278F5A3C4C8CD8E887CC2FF49A582C9912AD4926B64916B1F63B9880
    Session-ID: 57155155278F5A3C4C8CD8E887CC2FF49A582C9912AD4926B64916B1F63B9880
    Session-ID: 57155155278F5A3C4C8CD8E887CC2FF49A582C9912AD4926B64916B1F63B9880
    Session-ID: 57155155278F5A3C4C8CD8E887CC2FF49A582C9912AD4926B64916B1F63B9880

[gregw]

I think that API (sessionCachingEnabled) is really only meaningful on the client side! And then it is only supplying session reuse hints.

For the serverside, I think we need to set SslContext.getServerSessionContext().setSessionCacheSize(0);

We do have a setter for the session cache size... but I can't see the value actually being used! So at the very least there is a bug there!

I also think we need to check over the javadoc and make sure we are clear about server side and client side mechanisms....

Will do a bit more research before changing anything. If you get a chance to play before my research, if you could hack a call to SslContext.getServerSessionContext().setSessionCacheSize(0); it would be interesting to see if that had the desired effect of making the server reject session IDs offered in the client hello message.

[gregw]

Hmmm I can't actually find a way to disable the cache on the server side! Calling SslContext.getServerSessionContext().setSessionCacheSize(0) does not work because 0 means no cache size limit.

Similarly for SslContext.getServerSessionContext().setSessionTimeout(0) where 0 means no timeout.

The best I can currently find is to set the cache to size 1 with a timeout of 1s. But this will still reuse lots of sessions??? Googling....

[gregw]

I still cannot find a way to stop the server accepting a reuse if the client offers it?!?!?

[pranaydalmia]

I'm running into a similar problem. I looked at the JDK code and didn't see any obvious way of disabling SSL caching. This seems kind of hard to believe.

[gregw]

I've asked stack overflow

[gregw]

I cannot find a way to do this in JSSE, so unfortunately we cannot support it.
Closing for now.

[haus]

Cool. @gregw thanks for looking into this.

[mohanrao]

@gregw So current latest jetty behaviour is by default ssl caching enabled? If so what is default size of the cache.

[joakime]

session cache size is implementation specific. (it will be different in windows / linux / osx for example)

Use the default built-in API to determine what the cache size for your particular environment.

javax.net.ssl.SSLSessionContext.getSessionCacheSize()

[mohanrao]

then org.eclipse.jetty.util.ssl.SslContextFactory.setSslSessionCacheSize method has no effect ? what it is used for ? @joakime or @gregw can you please help me on this

[sbordet]

Jetty's SslContextFactory.setSslSessionCacheSize() is forwarded to JDK's SSLSessionContext.setSessionCacheSize().

The problem is that JDK's session cache size cannot be disabled.

[mohanrao]

so by default without doing anything the ssl cache is enabled in jetty?

[joakime]

@mohanrao by default, the ssl session cache is always enabled on the JVM. not possible to disable it or tune it down to 0 or 1 entry maximum (for example). That's the discovery that @gregw made. Its always active on the JVM, and not possible to disable.

[reidmv]

Assuming the underlying objective is to ensure that a session won't be re-used, it sounds like the way to do that is to immediately invalidate the session when it's established.

If a session is invalidated, I assume caching can be disregarded. The session should be unavailable for resuming or rejoining. Existing connections may continue to use the session until the connection is closed. Yes?

https://stackoverflow.com/questions/38912506/how-to-disable-javas-ssl-session-resumption
https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSession.html#invalidate--

Disclaimer: I'm not at all familiar with JSSE so someone else will need to check this. Was just rooting around the problem and found something that sounded plausible enough to be worth suggesting.

CC @haus

[joakime]

You could try that out, make a new class, extend it off of HttpConfiguration.Customizer.
In your implementation of ...

public void customize(Connector connector, HttpConfiguration channelConfig, Request request)

Unwrap the secure connection, get the endpoint, and invalidating the ssl session.

See SecureRequestCustomizer for some examples on how to unwrap to the ssl connection / endpoint.

When you are done, archive your new class in a new jar file.
Put it in your ${jetty.base}/lib/ext directory and enable the ext module in the start inis.

Then add it to your httpConfiguration.addCustomizer() to use it.