TLS/SSL Cache Automatic Purge

Server NGINX
1

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

2

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,
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
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
[email protected]

3

Hi B.R.,

Thank you very much for your answer and sorry for the US media political
like message :wink:

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:[email protected]] On Behalf Of B.R.
Sent: lundi 11 avril 2016 13:23
To: nginx ML [email protected]
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
, 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
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
<[email protected] mailto:[email protected] > 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

4

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.

Hardening Encrypted Communications Against Diffie-Hellman Precomputation Attacks - DomainTools | Start Here. Know Now.

what do others think about that?
Andreas

5

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,
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.
http://nginx.org/

6

Hello,

@Maxim
Just to be perfectly clear: does that mean that session tickets are
supported for any version of nginx (including <v1.5.9), provided OpenSSL
0.9.8f is available?
So the directive would be kind of ‘intercepting’ TLS commands, a man in
the
middle of client and OpenSSL?

@Arnaud
I guess the docs
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_timeout
have all your answers.

B. R.

7

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?

8

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:[email protected]] On Behalf Of B.R.
Sent: lundi 11 avril 2016 22:15
To: nginx ML [email protected]
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 <v1.5.9), provided OpenSSL
0.9.8f is available?

So the directive would be kind of ‘intercepting’ TLS commands, a man in
the middle of client and OpenSSL?

@Arnaud

I guess the docs
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_timeout
have all your answers.

B. R.

On Mon, Apr 11, 2016 at 3:31 PM, Maxim D. <[email protected]
mailto:[email protected] > 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,
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.
http://nginx.org/

9

Hi,

Just to be perfectly clear: does that mean that session tickets are
supported for any version of nginx (including <v1.5.9), provided
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] http://hg.nginx.org/nginx/rev/d049b0ea00a3
[2] https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_options.html

10

Hi!

I found these two opinions. They suggest to disable session tickets.

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