TLS/SSL Cache Automatic Purge

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

TLS/SSL Cache Automatic Purge

Arnaud Van der Vorst

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


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TLS/SSL Cache Automatic Purge

B.R.
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, 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 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 <[hidden email]> 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


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: TLS/SSL Cache Automatic Purge

Arnaud Van der Vorst

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


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx

 


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TLS/SSL Cache Automatic Purge

Maxim Dounin
In reply to this post by B.R.
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 Dounin
http://nginx.org/

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

opinions about Session tickets

A. Schulze

Maxim Dounin:

> 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://timtaubert.de/blog/2014/11/the-sad-state-of-server-side-tls-session-resumption-implementations/

what do others think about that?
Andreas


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TLS/SSL Cache Automatic Purge

B.R.
In reply to this post by Maxim Dounin
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 have all your answers.
---
B. R.

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

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: TLS/SSL Cache Automatic Purge

Arnaud Van der Vorst

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:[hidden email]] On Behalf Of B.R.
Sent: lundi 11 avril 2016 22:15
To: nginx ML <[hidden email]>
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 have all your answers.

---
B. R.

 

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


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx

 


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: opinions about Session tickets

Arnaud Van der Vorst
In reply to this post by A. Schulze
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?

-----Original Message-----
From: nginx [mailto:[hidden email]] On Behalf Of A. Schulze
Sent: lundi 11 avril 2016 17:17
To: [hidden email]
Subject: opinions about Session tickets


Maxim Dounin:

> 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://timtaubert.de/blog/2014/11/the-sad-state-of-server-side-tls-session-
resumption-implementations/

what do others think about that?
Andreas


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: opinions about Session tickets

Lukas Tribus
In reply to this post by A. Schulze
Hi!


> I found these two opinions. They suggest to disable session tickets.
>
> - https://www.farsightsecurity.com/Blog/20151202-thall-hardening-dh-and-ecc/
> -
> https://timtaubert.de/blog/2014/11/the-sad-state-of-server-side-tls-session-resumption-implementations/
>
> 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

     
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: TLS/SSL Cache Automatic Purge

Lukas Tribus
In reply to this post by B.R.
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

     
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RE: opinions about Session tickets

S.A.N
In reply to this post by Lukas Tribus
Hi Lukas,
I plan to use a key file on a tempfs on all my servers because we want to
comply with RFC5077.
Each time i change the key file with a new key, is it necessary to run a
"systemctl reload nginx" ? or do Something else.
If reload is not necessary, would working with 3 files always called the
same would be enough if i update the content with the new key ?
Like move remove file3, cp file2 to file3, cp file1 to file2, generate new
key in a new file1

Thanks

Alex

Posted at Nginx Forum: https://forum.nginx.org/read.php?2,266070,273272#msg-273272

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: RE: opinions about Session tickets

Lukas Tribus
> Each time i change the key file with a new key, is it necessary to run a
> "systemctl reload nginx" ? or do Something else.

Yes, afaik nginx requires a reload.

Haproxy can replace TLS tickets via admin socket [1] so a reload/restart is
not required, I'm not aware of similar nginx functionalities (but the reload
is less painless in nginx due to the master/worker concept).



> If reload is not necessary, would working with 3 files always called the
> same would be enough if i update the content with the new key ?
> Like move remove file3, cp file2 to file3, cp file1 to file2, generate new
> key in a new file1

No, that reload is necessary. Make sure you follow the advice in the doc
with multiple tickets, or actually, use the following approach:

ssl_session_ticket_key current.key;
ssl_session_ticket_key next.key;
ssl_session_ticket_key previous.key;

and something like this whenever you want to replace the tickets:
mv current.key previous.key
mv next.key current.key
"openssl rand 80 > next.key" (or rsyn to/from multiple servers)
/etc/init.d/nginx reload (or whatever the latest

That way, a new key will be distributed first, and only actively used for
encryption on the next reload, so regardless which server the client hits,
it always has an uptodate TLS ticket key, allowing decryption.


cheers,
lukas


[1] https://cbonte.github.io/haproxy-dconv/1.7/management.html#9.3-set%20ssl%20tls-key
[2] http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_ticket_key

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Loading...