Errors from browsers with ssl_session_tickets off (nginx)

Server
1

I’m trying to set up letsencrypt on a couple of my personal domains. I’ve used the same exact configuration for two: semianalog.com and misc.c4757p.com. On misc.c4757p.com, using the configuration recommended here, I get errors from Firefox and Chrome when trying to access the site - Firefox says SSL_ERROR_RX_UNEXPECTED_NEW_SESSION_TICKET; Chrome’s message is much more vague.

I only see a few references to this on the interwebs and everyone says to change ssl_session_tickets off to ssl_session_tickets on. That does indeed work, and that’s what I have in the configuration now, but I’d rather not have to do that. There must be a reason why it works on one of the sites and not the other!

nginx configuration for the broken site:

server {
    listen 80;
    listen [::]:80;
    server_name misc.c4757p.com;
    return 301 https://$http_host$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    ssl on;
    ssl_certificate /etc/letsencrypt/live/misc.c4757p.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/misc.c4757p.com/privkey.pem;
    include snippets/ssl-params.conf;
    root /srv/www/misc;
    ...

The working one is identical except for server_name semianalog.com www.semianalog.com, the path to the cert and key, and the server root path. The certs were created identically as well, using the command from that article.

snippets/ssl-params.conf is:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:10m;
#ssl_session_tickets off;
ssl_session_tickets on;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
ssl_dhparam /etc/ssl/certs/dhparam.pem;

Here’s the output of openssl s_client -connect misc.c4757p.com:443 -servername misc.c4757p.com with and without ssl_session_tickets:
https://misc.c4757p.com/session_tickets_on.txt
https://misc.c4757p.com/session_tickets_off.txt

Anyone see the problem?

P.S. “Title is invalid; try to be a little more descriptive” is evil and the same can be said to whoever wrote that message. I was able to shut it up by removing the actual error message text from the title. WTF.

2

Maybe use this:

ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;

source: https://mozilla.github.io/server-side-tls/ssl-config-generator/

BTW: Generally it is recommend to disable session tickets when using nginx as it would make Forward Secrecy useless.

3

Nope, same problem with that.

Indeed, that's why I'm trying to find a way to make it work with them off :stuck_out_tongue:

4

@rugk Thank you to emphasis that! I’ve reported it on two TLS scanner to help raise awareness:

https://github.com/ssllabs/ssllabs-scan/issues/367 ( https://github.com/aeris/cryptcheck/issues/21 )

https://github.com/aeris/cryptcheck/issues/21 ( https://tls.imirhil.fr/https used by https://mozilla.github.io/http-observatory-website/ )

2 Likes
5

I’m posting this here both because this question was recently asked and because it took me many hours of troubleshooting to figure out the issue as while I found several references to the problem on Google, no one seemed to have a real solution. So here it is:

ssl_session_tokens off breaks if it’s not set the same for all ssl-enabled server{} blocks. So if you have 2 server configurations and and you have ssl_server_tokens set to on in one (which is the default so it counts even if you omit it) and set to off in another, it will break the one where it’s set to off in certain browsers. The easiest way to resolve this, unless you have multiple http{} blocks, is to just set it to off in the http{} block. I have not tested to see if you you can have different settings in different http{} blocks as I haven’t had need to set up more than one http{} block.

For others looking for this issue, I want to add that Chrome will respond with: ERR_SSL_PROTOCOL_ERROR while Firefox responds with: SSL_ERROR_RX_UNEXPECTED_NEW_SESSION_TICKET and curl responds with: gnutls_handshake() failed: An unexpected TLS packet was received. IE seemed to work, surprisingly.

1 Like
6

Woo! That’s it! Must have been set improperly in one of the servers. I added it to http{} and everything is running swimmingly now. :thumbsup:

7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.