SSL Session caching in Apache HTTP Webserver
In this section, we will be looking at couple of stuffs as below :
- Is SSL Session Caching configured for Apache HTTP Webserver
- Testing SSL Session Caching (SSL session resumption)
Before we start over, lets have a basic understanding of what is SSL session caching and its significance.
SSL Session Caching (Session Resumption):
It is a performance optimization mechanism that is used to cache/save the SSL session (indicated by session ID) for a specified period of time after a given connection between the SSL client and server has been terminated. During this specified period of time, if the same SSL client attempts to reconnect to this SSL server and requests a resumption of a previous SSL session (by session ID), the costly cryptographic operations such as authentication and hand-shaking required to establish an SSL session is ignored, and the SSL server reactivates the SSL session that is cached from the previous connection with this same client.
SSL session resumption greatly improves performance when using SSL by recalling information from a previous successful SSL session negotiation to bypass the most computationally intensive parts of the SSL session key negotiation. HTTP is the protocol that benefits the most from SSL session resumption, but other Internet protocols may benefit as well.
Now having ourselves equipped with basic understanding of SSL session caching, let us proceed for the below technical stuffs.
How to find is ssl caching enabled on my webserver (apache http)
Check for the below “SSLSessionCache” directive in the ssl.conf file /etc/httpd/conf.d/ssl.conf
[root@linuxminion ~]# cat /etc/httpd/conf.d/ssl.conf | grep -i sessioncache SSLSessionCache shmcb:/run/httpd/sslcache(512000) SSLSessionCacheTimeout 300
The above values being Set indicates ssl session caching is enabled on web server.
The syntax of this directives are:
SSLSessionCache type where type is a storage type and its value can be any of the below supported types : - none - nonenotnull - dbm:/path/to/datafile - shmcb:/path/to/datafile[(size)] --> This is a recommended session cache by Apache [This makes use of a high-performance cyclic buffer (approx. size bytes in size) inside a shared memory segment in RAM (established via /path/to/datafile) to synchronize the local OpenSSL memory caches of the server processes. To use this, ensure that mod_socache_shmcb is loaded] - dc:UNIX:/path/to/socket SSLSessionCacheTimeout seconds This directive sets the timeout in seconds for the information stored in the global inter-process SSL Session Cache, the OpenSSL internal memory cache and for sessions resumed by TLS session resumption (RFC 5077). It can be set as low as 15 for testing, but should be set to higher values like 300 in real life.
Note: The dependency is that the apache module “socache_shmcb_module” needs to be loaded and this can be verified by running the below command.
[root@linuxminion]# httpd -M | grep shmcb socache_shmcb_module (shared) [root@linuxminion]# Where: -M Dump a list of loaded Static and Shared Modules.
Testing SSL Session Caching (SSL session resumption)
Test Case#1 : Using Openssl command
Executing the openssl command with the -reconnect switch can be used to test session reuse. In this mode, s_client will connect to the target server six times; it will create a new session on the first connection, then try to reuse the same session in the subsequent five connections as below.
The below output shows the New and Reused sessions with the same Session ID indicating that the SSL session caching is in place and working.
[root@linuxminion]# echo | openssl s_client -connect ec2-54-252-195-35.ap-southeast-2.compute.amazonaws.com:443 -reconnect 2>/dev/null| egrep -iw "New|Reused|Session-ID:" New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Session-ID: FF5C07F26F13973D3D9FB6800323442D7A8E0D9D5241AC5CF130539BBCEF5DFC Reused, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Session-ID: FF5C07F26F13973D3D9FB6800323442D7A8E0D9D5241AC5CF130539BBCEF5DFC Reused, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Session-ID: FF5C07F26F13973D3D9FB6800323442D7A8E0D9D5241AC5CF130539BBCEF5DFC Reused, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Session-ID: FF5C07F26F13973D3D9FB6800323442D7A8E0D9D5241AC5CF130539BBCEF5DFC Reused, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Session-ID: FF5C07F26F13973D3D9FB6800323442D7A8E0D9D5241AC5CF130539BBCEF5DFC Reused, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Session-ID: FF5C07F26F13973D3D9FB6800323442D7A8E0D9D5241AC5CF130539BBCEF5DFC [root@linuxminion]#
Test Case#2 : Using gnutls-cli command
Running the gnutls-cli command as below with -r (resume) option will actually connect to target server, establish a session, reconnect and resume the session.
The below output shows the Initial Connection with Session ID and then disconnects and reconnects back with the same Session ID indicating that the SSL Session caching is working.
[root@linuxminion]# gnutls-cli -V -r ec2-54-252-195-35.ap-southeast-2.compute.amazonaws.com | egrep -i "connect|reconnect|session" Connecting to '172.31.10.21:443'… Session ID: 5C:31:43:E9:74:44:C5:D4:43:CF:08:0F:05:D1:76:F3:07:FC:3C:06:BC:E3:6F:54:D3:A1:62:1B:28:FE:3C:2E Disconnecting Connecting again- trying to resume previous session Connecting to '172.31.10.21:443'… Session ID: 5C:31:43:E9:74:44:C5:D4:43:CF:08:0F:05:D1:76:F3:07:FC:3C:06:BC:E3:6F:54:D3:A1:62:1B:28:FE:3C:2E *** This is a resumed session ^C [root@linuxminion]#
NOTE: If you do not find the gnutls-cli command, install the corresponding gnutls-utils package to get the same.
Quick check – Run below gnutls-cli-debug command to check whether the server supports session resumption (Yes/No)
[root@linuxminion]# gnutls-cli-debug -p 443 ec2-54-252-195-35.ap-southeast-2.compute.amazonaws.com GnuTLS debug client 3.3.29 Checking ec2-54-252-195-35.ap-southeast-2.compute.amazonaws.com:443 for SSL 3.0 (RFC6101) support… no whether we need to disable TLS 1.2… no whether we need to disable TLS 1.1… no whether we need to disable TLS 1.0… no whether %NO_EXTENSIONS is required… no whether %COMPAT is required… no for TLS 1.0 (RFC2246) support… yes for TLS 1.1 (RFC4346) support… yes for TLS 1.2 (RFC5246) support… yes for HTTPS server name… Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips for certificate chain order… sorted for safe renegotiation (RFC5746) support… yes for heartbeat (RFC6520) support… yes for version rollback bug in RSA PMS… dunno for version rollback bug in Client Hello… no whether the server ignores the RSA PMS version… no whether small records (512 bytes) are accepted… yes whether cipher suites not in SSL 3.0 spec are accepted… yes whether a bogus TLS record version in the client hello is accepted… yes whether the server understands TLS closure alerts… partially whether the server supports session resumption… yes for anonymous authentication support… no for ephemeral Diffie-Hellman support… yes for ephemeral EC Diffie-Hellman support… yes ephemeral EC Diffie-Hellman group info… SECP256R1 for AES-128-GCM cipher (RFC5288) support… yes for AES-128-CBC cipher (RFC3268) support… yes for CAMELLIA-128-GCM cipher (RFC6367) support… no for CAMELLIA-128-CBC cipher (RFC5932) support… yes for 3DES-CBC cipher (RFC2246) support… yes for ARCFOUR 128 cipher (RFC2246) support… no for MD5 MAC support… no for SHA1 MAC support… yes for SHA256 MAC support… yes for ZLIB compression support… no for max record size (RFC6066) support… no for OCSP status response (RFC6066) support… no for OpenPGP authentication (RFC6091) support… no [root@linuxminion]#
Test using Qualys SSL Labs
If your SSL Web server is on the public Internet, then you can use Qualys SSL server test link https://www.ssllabs.com/ssltest/ to find a lot of details regarding SSL certificates, configuration, Session Resumption etc.
Snippet from the SSL Lab test output.