Bug 64497 - jni.SSL.getSessionId returns null
Summary: jni.SSL.getSessionId returns null
Status: RESOLVED FIXED
Alias: None
Product: Tomcat Native
Classification: Unclassified
Component: Library (show other bugs)
Version: 1.2.23
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-04 12:19 UTC by Remy Maucherat
Modified: 2020-08-20 08:24 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Remy Maucherat 2020-06-04 12:19:38 UTC
This can be reproduced using the following Tomcat test and OpenSSL using the build.properties:
test.entry=org.apache.catalina.valves.rewrite.TestResolverSSL
test.sslImplementation=org.apache.tomcat.util.net.openssl.OpenSSLImplementation

In the log, "[SSL_SESSION_ID] null", while many other fields work fine. jni.SSL.getSessionId simply returns null, so no SSL session id.
With JSSE, the SSL session id is there.
Comment 1 Mark Thomas 2020-08-19 22:38:42 UTC
The root cause of this behaviour is the session caching is hard-coded to disabled in sslcontext.c

That is a different default to OpenSSL. Some svn archaeology is called for to figure out why this was chosen as the default.

As a minimum, we need to expose the session cache mode and session cache size to the TLS connector. That is mostly going to be Tomcat code but I'll track it here for now.
Comment 2 Mark Thomas 2020-08-20 08:15:24 UTC
Turns out setting the session cache size was exposed and setting that automatically sets the mode correctly. The session ID is now available to the rewrite valve.

I still want to check on why the tomcat-native default is to disable this.
Comment 3 Mark Thomas 2020-08-20 08:24:18 UTC
It was part of the big patch from netty ~5 years ago. It isn't mentioned explicitly so I am guessing session caching was disabled by default because it isn't needed when RFC 5077 session tickets are available.