# TLS/SSL Cache Automatic Purge **URL:** \ **Category:** NGINX\ **Created:** [April 11, 2016, 10:42am UTC](https://www.ruby-forum.com/t/tls-ssl-cache-automatic-purge/244437 "2016-04-11T10:42:00Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Sadaf\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/858c86/32.png) [@Sadaf\_N](https://www.ruby-forum.com/u/Sadaf_N)\ **Post date:** [April 11, 2016, 10:42am UTC](https://www.ruby-forum.com/t/tls-ssl-cache-automatic-purge/244437/1 "2016-04-11T10:42:00Z")
Hi, My name is Arnaud and I am new to the list. I would like to know if NGINX is using any automatic purge mechanism for its TLS/SSL Cache configured using the following directives: ssl\_session\_timeout 10m; ssl\_session\_cache shared:SSL:10m; I understand that a daily purge of TLS/SSL Cache is highly recommended to avoid breaking Perfect Forward Secrecy of the TLS Protocol. If it does NOT use automatic purge, how can I purge the Shared cache used by NGINX then? Are there any command line tools for that purpose? Thank you very much in advance for your answer and have a nice day! Kind regards, Arnaud ---
**Author:** ![Arnaud\_Van\_der\_Vors](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/ad7895/32.png) [@Arnaud\_Van\_der\_Vors](https://www.ruby-forum.com/u/Arnaud_Van_der_Vors)\ **Post date:** [April 11, 2016, 1:24pm UTC](https://www.ruby-forum.com/t/tls-ssl-cache-automatic-purge/244437/2 "2016-04-11T13:24:30Z")
Sounds like US media political messages: ‘I am Arnaud, and I approve this message’. That said, welcome! You will have to write your own module if you want to manually delete TLS sessions parameters instead of letting them expire after 10 minutes. You could also emulate this daily purge by keeping stock nginx but setting : ssl\_session\_timeout 1d; albeit I for one do not recommend such settings since sessions parameters should probably not be remembered that long for several reasons… ## On a side-note, by default nginx does not store session parameters as it prefers tickets [http://nginx.org/en/docs/http/ngx\_http\_ssl\_module.html#ssl\_session\_tickets](http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_tickets), supported since v1.5.9, over sessions ID. The former is a more recent mechanism than the latter, and has the notable benefit of storing session parameters client-side, which scales, avoids cache management trouble as yours and some other ones. There are some docs [http://chimera.labs.oreilly.com/books/1230000000545/ch04.html#TLS\_RESUME](http://chimera.labs.oreilly.com/books/1230000000545/ch04.html#TLS_RESUME) about that in the Web tubes. Why not sticking with those defaults (or even set ssl\_session\_cache to off to be absolutely clear)? _B. R._ On Mon, Apr 11, 2016 at 10:41 AM, Arnaud Van der Vorst [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![Arnaud\_Van\_der\_Vors](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/ad7895/32.png) [@Arnaud\_Van\_der\_Vors](https://www.ruby-forum.com/u/Arnaud_Van_der_Vors)\ **Post date:** [April 11, 2016, 2:24pm UTC](https://www.ruby-forum.com/t/tls-ssl-cache-automatic-purge/244437/3 "2016-04-11T14:24:05Z")
Hi B.R., Thank you very much for your answer and sorry for the US media political like message 😉 So, if I understand correctly, using ssl\_session\_timeout makes sure that after the specified amount of time, the TLS/SSL Sessions will be removed/purged from the TLS/SSL Shared Cache? Is that correct? Kind regards, Arnaud From: nginx [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of B.R. Sent: lundi 11 avril 2016 13:23 To: nginx ML [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: TLS/SSL Cache Automatic Purge Sounds like US media political messages: ‘I am Arnaud, and I approve this message’. That said, welcome! You will have to write your own module if you want to manually delete TLS sessions parameters instead of letting them expire after 10 minutes. You could also emulate this daily purge by keeping stock nginx but setting : ssl\_session\_timeout 1d; albeit I for one do not recommend such settings since sessions parameters should probably not be remembered that long for several reasons… On a side-note, by default nginx does not store session parameters as it prefers tickets [http://nginx.org/en/docs/http/ngx\_http\_ssl\_module.html#ssl\_session\_tickets](http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_tickets) , supported since v1.5.9, over sessions ID. The former is a more recent mechanism than the latter, and has the notable benefit of storing session parameters client-side, which scales, avoids cache management trouble as yours and some other ones. There are some docs [http://chimera.labs.oreilly.com/books/1230000000545/ch04.html#TLS\_RESUME](http://chimera.labs.oreilly.com/books/1230000000545/ch04.html#TLS_RESUME) about that in the Web tubes. Why not sticking with those defaults (or even set ssl\_session\_cache to off to be absolutely clear)? * * * B. R. On Mon, Apr 11, 2016 at 10:41 AM, Arnaud Van der Vorst \ wrote: Hi, My name is Arnaud and I am new to the list. I would like to know if NGINX is using any automatic purge mechanism for its TLS/SSL Cache configured using the following directives: ssl\_session\_timeout 10m; ssl\_session\_cache shared:SSL:10m; I understand that a daily purge of TLS/SSL Cache is highly recommended to avoid breaking Perfect Forward Secrecy of the TLS Protocol. If it does NOT use automatic purge, how can I purge the Shared cache used by NGINX then? Are there any command line tools for that purpose? Thank you very much in advance for your answer and have a nice day! Kind regards, Arnaud ---
**Author:** ![Arnaud\_Van\_der\_Vors](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/ad7895/32.png) [@Arnaud\_Van\_der\_Vors](https://www.ruby-forum.com/u/Arnaud_Van_der_Vors)\ **Post date:** [April 11, 2016, 5:17pm UTC](https://www.ruby-forum.com/t/tls-ssl-cache-automatic-purge/244437/4 "2016-04-11T17:17:34Z")
Maxim D.: > In nginx 1.5.9 the “ssl\_session\_tickets” directive was added, > which makes it possible to disable session tickets when needed. I found these two opinions. They suggest to disable session tickets. - ## [https://www.farsightsecurity.com/Blog/20151202-thall-hardening-dh-and-ecc/](https://www.farsightsecurity.com/Blog/20151202-thall-hardening-dh-and-ecc/) > **[Botching Forward Secrecy - The sad state of server-side TLS Session...](https://timtaubert.de/blog/2014/11/the-sad-state-of-server-side-tls-session-resumption-implementations/)** > > Botching Forward Secrecy The sad state of server-side TLS Session Resumption implementations November 17, 2014 After you finished reading this one, … what do others think about that? Andreas ---
**Author:** ![Arnaud\_Van\_der\_Vors](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/ad7895/32.png) [@Arnaud\_Van\_der\_Vors](https://www.ruby-forum.com/u/Arnaud_Van_der_Vors)\ **Post date:** [April 11, 2016, 3:32pm UTC](https://www.ruby-forum.com/t/tls-ssl-cache-automatic-purge/244437/5 "2016-04-11T15:32:25Z")
Hello! On Mon, Apr 11, 2016 at 01:23:02PM +0200, B.R. wrote: […] > On a side-note, by default nginx does not store session parameters as it > prefers tickets > [http://nginx.org/en/docs/http/ngx\_http\_ssl\_module.html#ssl\_session\_tickets](http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_tickets), > supported since v1.5.9, over sessions ID. Session tickets supported as long as OpenSSL version used supports them, that is, with OpenSSL 0.9.8f or later. In nginx 1.5.9 the “ssl\_session\_tickets” directive was added, which makes it possible to disable session tickets when needed. – Maxim D. > **[nginx](http://nginx.org/)** ---
**Author:** ![Arnaud\_Van\_der\_Vors](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/ad7895/32.png) [@Arnaud\_Van\_der\_Vors](https://www.ruby-forum.com/u/Arnaud_Van_der_Vors)\ **Post date:** [April 11, 2016, 10:16pm UTC](https://www.ruby-forum.com/t/tls-ssl-cache-automatic-purge/244437/6 "2016-04-11T22:16:40Z")
Hello, @Maxim Just to be perfectly clear: does that mean that session tickets are supported for any version of nginx (including \ **Author:** ![Arnaud\_Van\_der\_Vors](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/ad7895/32.png) [@Arnaud\_Van\_der\_Vors](https://www.ruby-forum.com/u/Arnaud_Van_der_Vors)\ **Post date:** [April 12, 2016, 8:32am UTC](https://www.ruby-forum.com/t/tls-ssl-cache-automatic-purge/244437/7 "2016-04-12T08:32:57Z") Good morning, @Andreas Thank you for sharing these documents. I had already read the one from Tim Taubert and had the same concern about using TLS/SSL Tickets. Is it a good thing or not? ---
**Author:** ![Arnaud\_Van\_der\_Vors](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/ad7895/32.png) [@Arnaud\_Van\_der\_Vors](https://www.ruby-forum.com/u/Arnaud_Van_der_Vors)\ **Post date:** [April 12, 2016, 8:31am UTC](https://www.ruby-forum.com/t/tls-ssl-cache-automatic-purge/244437/8 "2016-04-12T08:31:12Z")
Hi, @B.R. Not really… The only information for ssl\_session\_timout is “Specifies a time during which a client may reuse the session parameters stored in a cache.” It does not say anything about purging the TLS/SSL Cache which is my concern here. I have read that invalidating a TLS/SSL Session and purging the TLS/SSL Cache are two separate things. Arnaud From: nginx [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of B.R. Sent: lundi 11 avril 2016 22:15 To: nginx ML [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) Subject: Re: TLS/SSL Cache Automatic Purge Hello, @Maxim Just to be perfectly clear: does that mean that session tickets are supported for any version of nginx (including \ wrote: Hello! On Mon, Apr 11, 2016 at 01:23:02PM +0200, B.R. wrote: […] > On a side-note, by default nginx does not store session parameters as it > prefers tickets > [http://nginx.org/en/docs/http/ngx\_http\_ssl\_module.html#ssl\_session\_tickets](http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_tickets), > supported since v1.5.9, over sessions ID. Session tickets supported as long as OpenSSL version used supports them, that is, with OpenSSL 0.9.8f or later. In nginx 1.5.9 the “ssl\_session\_tickets” directive was added, which makes it possible to disable session tickets when needed. – Maxim D. > **[nginx](http://nginx.org/)** ---
**Author:** ![Arnaud\_Van\_der\_Vors](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/ad7895/32.png) [@Arnaud\_Van\_der\_Vors](https://www.ruby-forum.com/u/Arnaud_Van_der_Vors)\ **Post date:** [April 12, 2016, 11:24am UTC](https://www.ruby-forum.com/t/tls-ssl-cache-automatic-purge/244437/9 "2016-04-12T11:24:07Z")
Hi, > Just to be perfectly clear: does that mean that session tickets are > supported for any version of nginx (including \ OpenSSL 0.9.8f is available? Yes. > So the directive would be kind of ‘intercepting’ TLS commands, a man in > the middle of client and OpenSSL? No, the feature [1] sets SSL\_OP\_NO\_TICKET [2], which instructs OpenSSL to NOT use TLS tickets. By default, OpenSSL uses tickets. > The only information for ssl\_session\_timout is Specifies a time during > which a client may reuse the session parameters stored in a cache. > It does not say anything about purging the TLS/SSL Cache which is my > concern here. I don’t think the sessions are purged, its probably an LRU. Lukas [1] [hg.nginx.org is decommissioned](http://hg.nginx.org/nginx/rev/d049b0ea00a3) [2] [Redirecting](https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_options.html) ---
**Author:** ![Arnaud\_Van\_der\_Vors](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/ad7895/32.png) [@Arnaud\_Van\_der\_Vors](https://www.ruby-forum.com/u/Arnaud_Van_der_Vors)\ **Post date:** [April 12, 2016, 11:18am UTC](https://www.ruby-forum.com/t/tls-ssl-cache-automatic-purge/244437/10 "2016-04-12T11:18:16Z")
Hi! > I found these two opinions. They suggest to disable session tickets. > > - [https://www.farsightsecurity.com/Blog/20151202-thall-hardening-dh-and-ecc/](https://www.farsightsecurity.com/Blog/20151202-thall-hardening-dh-and-ecc/) > - > **[Botching Forward Secrecy - The sad state of server-side TLS Session...](https://timtaubert.de/blog/2014/11/the-sad-state-of-server-side-tls-session-resumption-implementations/)** > > Botching Forward Secrecy The sad state of server-side TLS Session Resumption implementations November 17, 2014 After you finished reading this one, … > what do others think about that? Well, it depends: By default, unless you specify a tls ticket file (ssl\_session\_ticket\_key), a new key is generated when nginx is restarted, and the key is never written to disk. So for the session to get compromised, the attacker has to be able to extract the key from the servers memory, which will compromise all sessions using this ticket key. However, when the attacker has access to the memory the ticket key is stored, he probably can access the shared memory containg the session cache as well, which will compromise those session (not using tls tickets) too - the difference is that it will only compromise the sessions that are in the cache, while the ticket key can decrypt all sessions encrypted with it. I would say restart nginx once a day via cronjob to cycle the tls ticket key. Disabling tls tickets can be another workaround, yes, but all this is only relevant when the attacker gains access to your memory, which will reveal session cache and private key as well. If you have more than one server, you probably want to distribute and rotate the ticket key on all servers, in that case generate the tls ticket key in a central location and distribute it to all servers, never touching a permanent storage (don’t save to disk, use something like tmpfs). Lukas