Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why do you recommend disable ssl_session_tickets in NGINX? #135

Closed
nodesocket opened this issue Apr 1, 2016 · 21 comments
Closed

Why do you recommend disable ssl_session_tickets in NGINX? #135

nodesocket opened this issue Apr 1, 2016 · 21 comments

Comments

@nodesocket
Copy link

@nodesocket nodesocket commented Apr 1, 2016

Enabling should improve performance when used in conjunction with ssl_session_cache?

@tomato42
Copy link
Member

@tomato42 tomato42 commented Apr 1, 2016

Because proper rotation of session ticket encryption key is not implemented in nignx or Apache. Thus it is easier to recommend against its use that suggest use of 3rd party software to fix it.

@nodesocket
Copy link
Author

@nodesocket nodesocket commented Apr 1, 2016

Very strange, I've never heard about session tickets not being secure. Also, Qualys SSLabs does not warn about using session tickets.

@tomato42
Copy link
Member

@tomato42 tomato42 commented Apr 3, 2016

The problem is not that they are insecure, or that they can't be made secure. The problem is that the way they are commonly implemented means that you don't provide forward secrecy if you use them - all encryption keys are ultimately encrypted with just one encryption key - the session ticket key.

see here for more in-depth explanation: https://www.imperialviolet.org/2013/06/27/botchingpfs.html

@rugk
Copy link

@rugk rugk commented Jul 20, 2016

Basically it would make Perfect Forward Secrecy useless.

What about closing this issue as the question has presumably been answered?

@gene1wood
Copy link
Member

@gene1wood gene1wood commented Jul 20, 2016

Ya, looks like this has been answered. Thanks for the question @nodesocket and thanks everyone for the details about why.

@szepeviktor
Copy link
Contributor

@szepeviktor szepeviktor commented Mar 27, 2017

Apache docs is very clear about it:

Using them without restarting the web server with an appropriate frequency (e.g. daily) compromises perfect forward secrecy.

https://httpd.apache.org/docs/trunk/mod/mod_ssl.html

E.g. on Debian-based systems daily logrotate reloads Apache. I hope a reload is enough.

@tomato42
Copy link
Member

@tomato42 tomato42 commented Mar 29, 2017

IIRC reload is not sufficient, but it was a long time ago I last looked into it.

@szepeviktor
Copy link
Contributor

@szepeviktor szepeviktor commented Mar 29, 2017

IIRC reload is not sufficient, but it was a long time ago I last looked into it.

Thank you. Is there a programmatic way to clear the shared memory used by Apache for SSL?

@tomato42
Copy link
Member

@tomato42 tomato42 commented Mar 29, 2017

whole shared memory? I don't know

the ticket keys? two or three years ago there wasn't

@szepeviktor
Copy link
Contributor

@szepeviktor szepeviktor commented Mar 29, 2017

OK, so apache2ctl graceful

@april
Copy link
Contributor

@april april commented Mar 29, 2017

This is the same reason why we don't recommend using classic Diffie-Hellman key exchange. Sure, it can be done safely and correctly, but without web servers Doing The Right Thing (tm) automatically, it's prone to people screwing it up more often than not.

@szepeviktor
Copy link
Contributor

@szepeviktor szepeviktor commented Mar 30, 2017

apache2ctl graceful does change the session ticket.

Command used: openssl s_client -purpose "sslserver" -verify_return_error -connect www.egeszseges-ivoviz.hu:443 -servername www.egeszseges-ivoviz.hu < /dev/null

Output: TLS session ticket: ...

@szepeviktor
Copy link
Contributor

@szepeviktor szepeviktor commented Mar 30, 2017

Also 😄 service apache2 reload does change the session ticket.

@tomato42
Copy link
Member

@tomato42 tomato42 commented Mar 30, 2017

Just because you cannot resume the session after a server reload does not mean that the ticket encryption key has changed - sessions being invalidated will have the same result

@szepeviktor
Copy link
Contributor

@szepeviktor szepeviktor commented Apr 4, 2017

This is what I think.

This prints the TLS session ticket:

openssl s_client -purpose "sslserver" -verify_return_error \
 -connect www.egeszseges-ivoviz.hu:443 -servername www.egeszseges-ivoviz.hu \
< /dev/null 2> /dev/null | sed '/TLS session ticket:/,/^$/!d'

If I run it continuously the first 16 bytes don't change, only the rest.
When I reload apache apache2ctl graceful then the first 16 bytes also changes.
So I conclude that ticket encryption key is changed by the reload.

Am I right?

@tomato42
Copy link
Member

@tomato42 tomato42 commented Apr 11, 2017

From what I can see in openssl sources, the first 16 bytes of the ticket is the "name" of the key (essentially random data), so it changing does suggest the encryption key is changing too, but without looking into apache sources I can't tell for sure.

maybe you could find the bug in issue tracker that references it, we would know in which version they fixed the reload behaviour

@jrchamp
Copy link
Contributor

@jrchamp jrchamp commented Apr 11, 2017

Is it bad that the first 16 bytes are the same for all tickets generated by that key? Seems like it allows an attacker to know how often the key is changing (or not changing).

@tomato42
Copy link
Member

@tomato42 tomato42 commented Apr 19, 2017

correlating session resumption rates from clients will provide exact same information

sideshowbarker added a commit to whatwg/misc-server that referenced this issue Sep 5, 2017
See mozilla/server-side-tls#135

> proper rotation of session ticket encryption key is not
> implemented in nignx or Apache. Thus it is easier to recommend against
> its use that suggest use of 3rd party software to fix it.
> The problem is not that they are insecure, or that they can't be made
> secure. The problem is that the way they are commonly implemented means
> that you don't provide forward secrecy if you use them - all encryption
> keys are ultimately encrypted with just one encryption key - the session
> ticket key.
>
> see here for more in-depth explanation:
> https://www.imperialviolet.org/2013/06/27/botchingpfs.ht
andersk added a commit to andersk/zulip that referenced this issue Mar 9, 2019
Lengthen the session timeout and enlarge the session cache.  Disable
session tickets (see
mozilla/server-side-tls#135).  Upgrade
Diffie-Hellman parameters from fixed 1024-bit to custom 2048-bit.
Enable server-preferred cipher ordering, and OCSP stapling.

Signed-off-by: Anders Kaseorg <andersk@mit.edu>
andersk added a commit to andersk/zulip that referenced this issue Mar 9, 2019
Lengthen the session timeout and enlarge the session cache.  Disable
session tickets (see
mozilla/server-side-tls#135).  Upgrade
Diffie-Hellman parameters from fixed 1024-bit to custom 2048-bit.
Enable server-preferred cipher ordering, and OCSP stapling.

Signed-off-by: Anders Kaseorg <andersk@mit.edu>
andersk added a commit to andersk/zulip that referenced this issue Mar 9, 2019
Lengthen the session timeout and enlarge the session cache.  Disable
session tickets (see
mozilla/server-side-tls#135).  Upgrade
Diffie-Hellman parameters from fixed 1024-bit to custom 2048-bit.
Enable server-preferred cipher ordering, and OCSP stapling.

Signed-off-by: Anders Kaseorg <andersk@mit.edu>
andersk added a commit to andersk/zulip that referenced this issue Mar 11, 2019
Lengthen the session timeout and enlarge the session cache.  Disable
session tickets (see
mozilla/server-side-tls#135).  Upgrade
Diffie-Hellman parameters from fixed 1024-bit to custom 2048-bit.
Enable OCSP stapling.

Signed-off-by: Anders Kaseorg <andersk@mit.edu>
andersk added a commit to andersk/zulip that referenced this issue Mar 11, 2019
Lengthen the session timeout and enlarge the session cache.  Disable
session tickets (see
mozilla/server-side-tls#135).  Upgrade
Diffie-Hellman parameters from fixed 1024-bit to custom 2048-bit.
Enable OCSP stapling.

Signed-off-by: Anders Kaseorg <andersk@mit.edu>
andersk added a commit to andersk/zulip that referenced this issue Mar 12, 2019
Lengthen the session timeout and enlarge the session cache.  Disable
session tickets (see
mozilla/server-side-tls#135).  Upgrade
Diffie-Hellman parameters from fixed 1024-bit to custom 2048-bit.
Enable OCSP stapling.

Signed-off-by: Anders Kaseorg <andersk@mit.edu>
davidbgk added a commit to betagouv/zam that referenced this issue Oct 11, 2019
autorebase bot pushed a commit to betagouv/zam that referenced this issue Oct 14, 2019
autorebase bot pushed a commit to betagouv/zam that referenced this issue Oct 14, 2019
autorebase bot pushed a commit to betagouv/zam that referenced this issue Oct 14, 2019
autorebase bot added a commit to betagouv/zam that referenced this issue Oct 14, 2019
@jessuppi
Copy link

@jessuppi jessuppi commented Dec 6, 2019

After a decade of SSL evolution, session tickets are still not handled properly by major servers, with the exception of perhaps Caddy, a minor player. Here are a few good explanations:

Ref: https://timtaubert.de/blog/2017/02/the-future-of-session-resumption/

Ref: https://medium.com/@vanrijn/what-is-new-with-tls-1-3-e991df2caaac

Even years later, I've yet to see any common scenario mentioned anywhere for implementing it, even theoretically (e.g. if cycling the tickets were in fact easy to do)... and moreover, it seems to be a concept that never caught on, if only for its technical challenges.

TLDR: As mentioned in the links, session IDs and session tickets are "dead" in TLS 1.3.

@april
Copy link
Contributor

@april april commented Dec 6, 2019

Yeah, I kept waiting for Apache and nginx to simply Do The Right Thing(tm) in this regards, but somehow they just… never changed. Thankfully things are far more sane in TLS 1.3.

Miss-you added a commit to Miss-you/incubator-apisix that referenced this issue Nov 9, 2020
membphis pushed a commit to apache/apisix that referenced this issue Nov 9, 2020
fix #2638

In a word, 'ssl_session_tickets' would make Perfect Forward Secrecy useless.

reference:
ingress-nginx:kubernetes/ingress-nginx#6196
mozilla:mozilla/server-side-tls#135
@gstrauss
Copy link

@gstrauss gstrauss commented Nov 30, 2020

Yeah, I kept waiting for Apache and nginx to simply Do The Right Thing(tm) in this regards, but somehow they just… never changed.

lighttpd 1.4.56 attempts to "do a secure thing". By default, session ticket encryption keys are rotated periodically rather than potentially having an unlimited lifetime. lighttpd 1.4.56 also give admins a mechanism to generate session ticket encryption keys and synchronize the session ticket encryption keys across multiple servers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
9 participants