# SSL session resumption. SSL Labs test **URL:** \ **Category:** NGINX\ **Created:** [November 21, 2010, 11:50pm UTC](https://www.ruby-forum.com/t/ssl-session-resumption-ssl-labs-test/199453 "2010-11-21T23:50:18Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![okkezSS](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/o/85f322/32.png) [@okkezSS](https://www.ruby-forum.com/u/okkezSS)\ **Post date:** [November 21, 2010, 11:50pm UTC](https://www.ruby-forum.com/t/ssl-session-resumption-ssl-labs-test/199453/1 "2010-11-21T23:50:18Z")
I’ve run a test through the tool available here: > **[SSL Server Test (Powered by Qualys SSL Labs)](https://www.ssllabs.com/ssltest/index.html)** > > A comprehensive free SSL test for your public web servers. And I get a result stating: Session resumption No (IDs assigned but not accepted) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I also run gnutls-cli and get: Checking for Safe renegotiation support… yes Checking for Safe renegotiation support (SCSV)… yes Checking for TLS 1.2 support… no Checking for TLS 1.1 support… no Checking fallback from TLS 1.1 to… TLS 1.0 Checking for TLS 1.0 support… yes Checking for SSL 3.0 support… yes Checking for HTTPS server name… not checked Checking for version rollback bug in RSA PMS… no Checking for version rollback bug in Client Hello… no Checking whether we need to disable TLS 1.0… N/A Checking whether the server ignores the RSA PMS version… no Checking whether the server can accept Hello Extensions… yes Checking whether the server can accept cipher suites not in SSL 3.0 spec… yes Checking whether the server can accept a bogus TLS record version in the client hello… no Checking for certificate information… N/A Checking for trusted CAs… N/A Checking whether the server understands TLS closure alerts… partially Checking whether the server supports session resumption… no ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ It’s strange, since I have the shared cache enabled: ``` ## Use a SSL/TLS cache for SSL session resume. ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; ``` Isn’t this enough? Can someone more knowledgeable than I in SSL/TLS stuff and Nginx shed some light on this issue? Should I ignore this result? Thank you, — appa ---
**Author:** ![SSAntS\_nio\_PSPSAlm](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e47774/32.png) [@SSAntS\_nio\_PSPSAlm](https://www.ruby-forum.com/u/SSAntS_nio_PSPSAlm)\ **Post date:** [November 21, 2010, 11:56pm UTC](https://www.ruby-forum.com/t/ssl-session-resumption-ssl-labs-test/199453/2 "2010-11-21T23:56:34Z")
On Sun, Nov 21, 2010 at 11:43 PM, Antnio P. P. Almeida [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > … > Isn’t this enough? Can someone more knowledgeable than I in SSL/TLS > stuff and Nginx shed some light on this issue? Should I ignore this > result? The case might be that Qualys SSL Labs checks all this against the IP address it resolves from the domain you give them. Apply those SSL settings to the default server to make this all work there. If these settings are already in place or if the problem persists after that, please post here again! Regards, Luit van Drongelen ---
**Author:** ![SSAntS\_nio\_PSPSAlm](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e47774/32.png) [@SSAntS\_nio\_PSPSAlm](https://www.ruby-forum.com/u/SSAntS_nio_PSPSAlm)\ **Post date:** [November 22, 2010, 1:57am UTC](https://www.ruby-forum.com/t/ssl-session-resumption-ssl-labs-test/199453/3 "2010-11-22T01:57:17Z")
On 21 Nov 2010 22h55 WET, [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > On Sun, Nov 21, 2010 at 11:43 PM, António P. P. Almeida > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > > … > > Isn’t this enough? Can someone more knowledgeable than I in SSL/TLS > > stuff and Nginx shed some light on this issue? Should I ignore this > > result? > > The case might be that Qualys SSL Labs checks all this against the > IP address it resolves from the domain you give them. Apply those > SSL settings to the default server to make this all work there. My default\_server is used to block illegal host headers. So I have a ‘\_’ as server\_name. Although I have more sites running on this IP, currently this is the only site on SSL/TLS. Isn’t this enough? Note also that the GnuTLS client gave the same result. — appa ---
**Author:** ![SSAntS\_nio\_PSPSAlm](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e47774/32.png) [@SSAntS\_nio\_PSPSAlm](https://www.ruby-forum.com/u/SSAntS_nio_PSPSAlm)\ **Post date:** [November 22, 2010, 2:16am UTC](https://www.ruby-forum.com/t/ssl-session-resumption-ssl-labs-test/199453/4 "2010-11-22T02:16:40Z")
On 21 Nov 2010 22h55 WET, [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > On Sun, Nov 21, 2010 at 11:43 PM, António P. P. Almeida > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > > … > > Isn’t this enough? Can someone more knowledgeable than I in SSL/TLS > > stuff and Nginx shed some light on this issue? Should I ignore this > > result? > > The case might be that Qualys SSL Labs checks all this against the > IP address it resolves from the domain you give them. Apply those > SSL settings to the default server to make this all work there. You’re right I tried with GnuTLS against my localhost that has a “regular” default\_server and it works: Checking whether the server understands TLS closure alerts… partially Checking whether the server supports session resumption… yes ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Also in this server there’s no setting in the config for ssl\_session\_cache. Its using the default value: none. This means that the problem resides in the way the test is performed? Can you elaborate a little bit more? Thank you, — appa ---
**Author:** ![SSAntS\_nio\_PSPSAlm](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e47774/32.png) [@SSAntS\_nio\_PSPSAlm](https://www.ruby-forum.com/u/SSAntS_nio_PSPSAlm)\ **Post date:** [November 22, 2010, 2:30am UTC](https://www.ruby-forum.com/t/ssl-session-resumption-ssl-labs-test/199453/5 "2010-11-22T02:30:26Z")
On 21 Nov 2010 22h55 WET, [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > On Sun, Nov 21, 2010 at 11:43 PM, António P. P. Almeida > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > > … > > Isn’t this enough? Can someone more knowledgeable than I in SSL/TLS > > stuff and Nginx shed some light on this issue? Should I ignore this > > result? > > The case might be that Qualys SSL Labs checks all this against the > IP address it resolves from the domain you give them. Apply those > SSL settings to the default server to make this all work there. Ok. I think I get it. The test doesn’t use SNI. Hence it checks against the default\_server for the session resumption test. Since in this case this is just a regular HTTP server block with ‘\_’ as server name it doesn’t associate the server where the certficate is installed with the session resumption test. Is that it? Thanks, — appa ---
**Author:** ![SSAntS\_nio\_PSPSAlm](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e47774/32.png) [@SSAntS\_nio\_PSPSAlm](https://www.ruby-forum.com/u/SSAntS_nio_PSPSAlm)\ **Post date:** [November 22, 2010, 4:03am UTC](https://www.ruby-forum.com/t/ssl-session-resumption-ssl-labs-test/199453/6 "2010-11-22T04:03:38Z")
Hello! On Mon, Nov 22, 2010 at 01:24:01AM +0000, António P. P. Almeida wrote: > > IP address it resolves from the domain you give them. Apply those > > SSL settings to the default server to make this all work there. > > Ok. I think I get it. The test doesn’t use SNI. Hence it checks > against the default\_server for the session resumption test. Since in > this case this is just a regular HTTP server block with ‘\_’ as server > name it doesn’t associate the server where the certficate is installed > with the session resumption test. > > Is that it? Session establishmen/resumption happens before SNI handling. Therefore configuring session cache within SNI-only server{} won’t work, you have to configure one in default server for the socket in question. This is how it’s done in OpenSSL, and it seems to be what actually required by RFC4366 ([RFC 4366: Transport Layer Security (TLS) Extensions | RFC Editor](http://tools.ietf.org/html/rfc4366#section-3)): - If, on the other hand, the older session is resumed, then the server MUST ignore the extensions and send a server hello containing none of the extension types. In this case, the functionality of these extensions negotiated during the original session initiation is applied to the resumed session. One can’t resume session stored somewhere in server name related context while following “MUST ignore” rule. Maxim D. ---
**Author:** ![SSAntS\_nio\_PSPSAlm](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e47774/32.png) [@SSAntS\_nio\_PSPSAlm](https://www.ruby-forum.com/u/SSAntS_nio_PSPSAlm)\ **Post date:** [November 22, 2010, 4:00pm UTC](https://www.ruby-forum.com/t/ssl-session-resumption-ssl-labs-test/199453/7 "2010-11-22T16:00:16Z")
On 22 Nov 2010 03h02 WET, removed\_email\_address@domain.invalid wrote: Ok I was a bit tired yesterday and ended up putting the: ``` listen [::]:443 ssl default_server; # ipv6 ``` Not in the “real” server block, but in the redirect 🙂 It works like this (although it also works with regular HTTP and a default\_server setting). I’ve updated the wiki to make this caveat more explicit: [http://wiki.nginx.org/HttpSslModule#ssl\_session\_cache](http://wiki.nginx.org/HttpSslModule#ssl_session_cache) Thanks to everyone who helped me sort out this issue. António, — appa ---
**Author:** ![SSAntS\_nio\_PSPSAlm](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e47774/32.png) [@SSAntS\_nio\_PSPSAlm](https://www.ruby-forum.com/u/SSAntS_nio_PSPSAlm)\ **Post date:** [November 22, 2010, 4:45am UTC](https://www.ruby-forum.com/t/ssl-session-resumption-ssl-labs-test/199453/8 "2010-11-22T04:45:40Z")
On 22 Nov 2010 03h02 WET, [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: Hello Maxim, Thank you for your reply. > Session establishmen/resumption happens before SNI handling. > Therefore configuring session cache within SNI-only server{} won’t > work, you have to configure one in default server for the socket > in question. So the session resumption is done using a mapping that related IPs with session IDs. Completely oblivious to anything related with server\_name. > This is how it’s done in OpenSSL, and it seems to be what actually > required by RFC4366 ([RFC 4366: Transport Layer Security (TLS) Extensions | RFC Editor](http://tools.ietf.org/html/rfc4366#section-3)): > > - If, on the other hand, the older session is resumed, then the > server MUST ignore the extensions and send a server hello > containing none of the extension types. In this case, the > functionality of these extensions negotiated during the original > session initiation is applied to the resumed session. I tried this: listen [::]:443 ssl default\_server; # ipv6 while leaving the ‘\_’ server\_name for the HTTP default server. But gnutls-bin gives the same results. No session resumption support. It requires a regular default\_server, i.e., listen [::]:80 default\_server; # ipv6 And the session cache configured in the correct server. This means that I must ditch the “illegal” Host header server block so it seems in order to get SSL session resumption to work ☹ — appa ---
**Author:** ![SSAntS\_nio\_PSPSAlm](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e47774/32.png) [@SSAntS\_nio\_PSPSAlm](https://www.ruby-forum.com/u/SSAntS_nio_PSPSAlm)\ **Post date:** [November 22, 2010, 4:27pm UTC](https://www.ruby-forum.com/t/ssl-session-resumption-ssl-labs-test/199453/9 "2010-11-22T16:27:59Z")
Hello! On Mon, Nov 22, 2010 at 03:39:06AM +0000, António P. P. Almeida wrote: > > in question. > > containing none of the extension types. In this case, the > > functionality of these extensions negotiated during the original > > session initiation is applied to the resumed session. > > I tried this: > > listen [::]:443 ssl default\_server; # ipv6 > > while leaving the ‘\_’ server\_name for the HTTP default server. But > gnutls-bin gives the same results. No session resumption support. It > requires a regular default\_server, i.e., I’ve played a bit with this, and it seems the only working configuration is having identical ssl\_session\_cache in all SNI server{}'s. Anything else will not work due to the fact that OpenSSL uses initial context (i.e. default server’s one) for session caching, but current context (i.e. server name matched server’s) e.g. to decide whether advertise session id to client or not. I.e. the following configuration will not cache sessions to “[test.example.com](http://test.example.com)”: ``` ssl_session_cache off; server { listen 443 ssl default; ssl_session_cache shared:SSL:10m; ... } server { listen 443; server_name test.example.com; ... } ``` Additionally, when shared cache is used, nginx will be confused by new session/remove session callbacks called with ssl connection with context which is not expected to have any session callbacks. E.g. this configuration will generate SIGSEGV on request to “[test.example.com](http://test.example.com)”: ``` server { listen 443 ssl default; ssl_session_cache shared:SSL:10m; ... } server { listen 443; server_name test.example.com; ssl_session_cache builtin; ... } ``` Simpliest (and recommended) workaround for both problems is to use ssl\_session\_cache defined at http{} level. I.e. ``` ssl_session_cache shared:SSL:10m; server { ... } ... ``` Maxim D. ---
**Author:** ![SSAntS\_nio\_PSPSAlm](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e47774/32.png) [@SSAntS\_nio\_PSPSAlm](https://www.ruby-forum.com/u/SSAntS_nio_PSPSAlm)\ **Post date:** [November 22, 2010, 5:42pm UTC](https://www.ruby-forum.com/t/ssl-session-resumption-ssl-labs-test/199453/10 "2010-11-22T17:42:03Z")
On 22 Nov 2010 15h26 WET, [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: Hello Maxim, > I’ve played a bit with this, and it seems the only working > configuration is having identical ssl\_session\_cache in all > SNI server{}'s. I’ve re-updated the Wiki and indicated that as the _preferred_ approach. > server { > > } > > server { > listen 443; > server\_name [test.example.com](http://test.example.com); > ssl\_session\_cache builtin; > … > } > > Simpliest (and recommended) workaround for both problems is to use > ssl\_session\_cache defined at http{} level. I.e. I’ve re-updated the Wiki and indicated that as the _preferred_ approach. Going off in a tangent. Does the usage of GNU TLS instead of OpenSSL as the underlying crypto library might mitigate this? There’s now a mod\_gnutls for Apache. And it would be nice if Nginx had also “competing” crypto modules. Just an idea. Thanks, — appa