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
Comments
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. |
Very strange, I've never heard about session tickets not being secure. Also, Qualys SSLabs does not warn about using session tickets. |
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 |
Basically it would make Perfect Forward Secrecy useless. What about closing this issue as the question has presumably been answered? |
Ya, looks like this has been answered. Thanks for the question @nodesocket and thanks everyone for the details about why. |
Apache docs is very clear about it:
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. |
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? |
whole shared memory? I don't know the ticket keys? two or three years ago there wasn't |
OK, so |
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. |
Command used: Output: |
Also 😄 |
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 |
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. Am I right? |
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 |
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). |
correlating session resumption rates from clients will provide exact same information |
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
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>
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>
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>
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>
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
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. |
nginx guarantees that it switches the built-in key on reload but that's not really what you want. You want to rotate them rather than suddenly invalidating all of the previous ones. To do the right thing, you have to script it externally and reference the keys with http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_ticket_key You need that if you want to sync them across servers, but you shouldn't need this for the simple case. It's a similar situation as OCSP stapling where you can use an approach like https://github.com/tomwassenberg/certbot-ocsp-fetcher to persistently cache a valid response externally and reference it from the server, but they don't give you an easy way to do the right thing internally, which is strange. Neither of these things would be particularly hard for them to implement properly internally. It would be simpler than what you need to do with scripts... |
It's default turned on, but it's better to turn it off for security reason. Reference: - https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_tickets - mozilla/server-side-tls#135
It's default turned on, but it's better to turn it off for security reason. Reference: - https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_tickets - mozilla/server-side-tls#135
The GrapheneOS project already has this in place; see https://github.com/GrapheneOS/nginx-rotate-session-ticket-keys and the relevant nginx configs. Incidentally, using certbot-ocsp-fetcher and the GrapheneOS scripts allows you to get 0-RTT working with the OCSP must-staple patch for BoringSSL-based Nginx servers. |
It's default turned on, but it's better to turn it off for security reason. Reference: - https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_tickets - mozilla/server-side-tls#135
Does nginx 1.23.2 changes this?
|
Wow finally, yeah! 🎉 |
Before 1.23.2, it didn't explicitly purge state-based sessions from the cache either. Neither the stateless (session tickets) or stateful approaches provided proper forward secrecy. The only proper approach before 1.23.2 was configuring session ticket keys via external files in ramfs managed by a script reloading the nginx configuration after rotating them. Both approaches can now work without it. It's not explicitly mentioned in the release notes, but it changed too.
|
Enabling should improve performance when used in conjunction with
ssl_session_cache
?The text was updated successfully, but these errors were encountered: