# TLS session resumption (identifier) **URL:** \ **Category:** NGINX\ **Created:** [March 3, 2016, 12:44pm UTC](https://www.ruby-forum.com/t/tls-session-resumption-identifier/244191 "2016-03-03T12:44:09Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Rafa\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/958977/32.png) [@Rafa\_F](https://www.ruby-forum.com/u/Rafa_F)\ **Post date:** [March 3, 2016, 12:44pm UTC](https://www.ruby-forum.com/t/tls-session-resumption-identifier/244191/1 "2016-03-03T12:44:09Z")
Hello, Based on the default value of ssl\_session\_cache [http://nginx.org/en/docs/http/ngx\_http\_ssl\_module.html#ssl\_session\_cache](http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_cache), nginx does not store any session parameter, but allows client with the right Master Key to reuse their ID (and the parameters they got). Since nginx, does not cache anything and is thus unable to revalidate anything but the Master Key, isn’t it a violation of the RFC not to validate all the parameters? What happens in the following scenario? 1°) Client negociates a new TLS session and stores the session ID locally 2°) Server admin changes the configuration of his/her server to completely alter cipher suites, etc. and reloads the configuration (without restarting the server, so the Master Key is left untouched) 3°) Client tries to reuse its previously saved session ID with the right Master Key I guess the server will most probably reject the session bacu and initiate a new one with the same Master Key (please confirm)? Is it ‘legal’? I admit that, in a way, the same happens when say, on a high-traffic server, the cache rotation eliminates old entries which a client then tries to resume a session with… ## Is it allowed to reduce the session ID mechanism to the check of the Master Key per RFC? Shouldn’t you either fully support the mechanism (with a cache of parameters server-side) or not at all? _B. R._ ---
**Author:** ![B.R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/3be4f8/32.png) [@B.R](https://www.ruby-forum.com/u/B.R)\ **Post date:** [March 3, 2016, 2:29pm UTC](https://www.ruby-forum.com/t/tls-session-resumption-identifier/244191/2 "2016-03-03T14:29:53Z")
Hello! On Thu, Mar 03, 2016 at 12:42:55PM +0100, B.R. wrote: > Based on the default value of ssl\_session\_cache > [http://nginx.org/en/docs/http/ngx\_http\_ssl\_module.html#ssl\_session\_cache](http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_cache), > nginx does not store any session parameter, but allows client with the > right Master Key to reuse their ID (and the parameters they got). > > Since nginx, does not cache anything and is thus unable to revalidate > anything but the Master Key, isn’t it a violation of the RFC not to > validate all the parameters? You are misunderstanding what “ssl\_session\_cache none” does. It doesn’t allow anything to be reused, just says so to clients. – Maxim D. > **[nginx](http://nginx.org/)** ---
**Author:** ![B.R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/3be4f8/32.png) [@B.R](https://www.ruby-forum.com/u/B.R)\ **Post date:** [March 3, 2016, 4:43pm UTC](https://www.ruby-forum.com/t/tls-session-resumption-identifier/244191/3 "2016-03-03T16:43:39Z")
Thanks, Maxim. You were right: I did my tests improperly… ## What is the use of the ‘none’ value then? Should not there be only the ‘off’ one? There must be some benefit to it, but I fail to catch it. _B. R._ ---
**Author:** ![B.R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/3be4f8/32.png) [@B.R](https://www.ruby-forum.com/u/B.R)\ **Post date:** [March 3, 2016, 4:49pm UTC](https://www.ruby-forum.com/t/tls-session-resumption-identifier/244191/4 "2016-03-03T16:49:30Z")
On 03 Mar 2016, at 18:42, B.R. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Thanks, Maxim. > > You were right: I did my tests improperly… > > What is the use of the ‘none’ value then? Should not there be only the ‘off’ > one? > There must be some benefit to it, but I fail to catch it. Initially it has been implemented for mail proxy module, but it seems that none is more graceful than off in general: ``` /* * If the server explicitly says that it does not support * session reuse (see SSL_SESS_CACHE_OFF above), then * Outlook Express fails to upload a sent email to * the Sent Items folder on the IMAP server via a separate IMAP * connection in the background. Therefore we have a special * mode (SSL_SESS_CACHE_SERVER|SSL_SESS_CACHE_NO_INTERNAL_STORE) * where the server pretends that it supports session reuse, * but it does not actually store any session. */ ``` – Igor S. > **[F5 NGINX: Built for cloud-native apps. Ready for AI traffic.](https://www.f5.com/products/nginx)** > > Deliver modern applications with NGINX. Explore high-performance load balancing, API gateways, and web server solutions trusted by top global enterprises. ---
**Author:** ![B.R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/3be4f8/32.png) [@B.R](https://www.ruby-forum.com/u/B.R)\ **Post date:** [March 4, 2016, 10:09am UTC](https://www.ruby-forum.com/t/tls-session-resumption-identifier/244191/5 "2016-03-04T10:09:19Z")
Thanks Igor, that makes the whole thing crystal clear! What saves us there is the fact that, if I understand it well, the RFC 5077 [https://tools.ietf.org/html/rfc5077#section-3.4](https://tools.ietf.org/html/rfc5077#section-3.4)​ states the server decides by itself on the use of tickets and those have precedence over identifiers. But still, advertising something without actually supporting it must lead to cases where sessions reuse is believed to take place without ever happening, harming performance… that was probably happening in versions \< 1.5.9. ## Giving the possibility to accomodate with Outlook (and Microsoft products in general) numerous quirks is fine, but making it the default is debatable… Maybe the docs should be more explicit about the reason of the existence of ‘none’? Code comments are clearer than the docs on this matter. _B. R._ ---
**Author:** ![B.R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/3be4f8/32.png) [@B.R](https://www.ruby-forum.com/u/B.R)\ **Post date:** [March 4, 2016, 10:33am UTC](https://www.ruby-forum.com/t/tls-session-resumption-identifier/244191/6 "2016-03-04T10:33:51Z")
On 04 Mar 2016, at 12:08, B.R. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Thanks Igor, that makes the whole thing crystal clear! > > What saves us there is the fact that, if I understand it well, the RFC 5077​ > states the server decides by itself on the use of tickets and those have > precedence over identifiers. Yes. > But still, advertising something without actually supporting it must lead to > cases where sessions reuse is believed to take place without ever happening, > harming performance… that was probably happening in versions \< 1.5.9. I do not think that it should harm performance. > Giving the possibility to accomodate with Outlook (and Microsoft products in > general) numerous quirks is fine, but making it the default is debatable… I believe this is safe default and clients should not rely on resumed sessions because 1. sessions have timeout defined by server security policy, 2. and server has limited session storage so old sessions are removed. > Maybe the docs should be more explicit about the reason of the existence of > ‘none’? Code comments are clearer than the docs on this matter. Yes, probably. – Igor S. > **[F5 NGINX: Built for cloud-native apps. Ready for AI traffic.](https://www.f5.com/products/nginx)** > > Deliver modern applications with NGINX. Explore high-performance load balancing, API gateways, and web server solutions trusted by top global enterprises. ---
**Author:** ![B.R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/3be4f8/32.png) [@B.R](https://www.ruby-forum.com/u/B.R)\ **Post date:** [March 4, 2016, 11:20am UTC](https://www.ruby-forum.com/t/tls-session-resumption-identifier/244191/7 "2016-03-04T11:20:01Z")
On 04 Mar 2016, at 12:55, B.R. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > On Fri, Mar 4, 2016 at 10:33 AM, Igor S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > > But still, advertising something without actually supporting it must lead to > > cases where sessions reuse is believed to take place without ever happening, > > harming performance… that was probably happening in versions \< 1.5.9. > > I do not think that it should harm performance. > > ​Oh yes it does​… I am surprised by your stance and I beg to differ. > Having quite some load from many clients on a web-server delivering content over > HTTPS, it relieves a lot of pain to save CPU cycles by avoiding a full handshake. > When a client browses a website, (s)he will initiate many connections. Beyond > the first one (ones with multiplexing?), session reuse kicks in. Repeat that for > each client and sum all the saved CPU cycles. Even an improper (non-scientific) > benchmark will show you improvement. > > Session reuse is part of the effort of optimizing TLS trafic to minimize its > overhead. Have a talk about it with the W3C webperf group if you wish, to which > Ilya G. (participated at nginxconf 2014) belongs. Have a look at his > checklist too.​ Sorry, I meant there is no performance difference between “none” and “off” settings. As to default value, builtin session cache was by default initially but it turned out that it leads to memory fragmentation. So the default value has been changed to “off” and later to “none”. Of course shared cache is certainly better as default value but there is no good understanding what default cache size should be used. And now it becomes less important with ticket introduction. ---
**Author:** ![B.R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/3be4f8/32.png) [@B.R](https://www.ruby-forum.com/u/B.R)\ **Post date:** [March 4, 2016, 10:57am UTC](https://www.ruby-forum.com/t/tls-session-resumption-identifier/244191/8 "2016-03-04T10:57:13Z")
On Fri, Mar 4, 2016 at 10:33 AM, Igor S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > But still, advertising something without actually supporting it must lead > to cases where sessions reuse is believed to take place without ever > happening, harming performance… that was probably happening in versions \< > 1.5.9. > > I do not think that it should harm performance. ​Oh yes it does​… I am surprised by your stance and I beg to differ. Having quite some load from many clients on a web-server delivering content over HTTPS, it relieves a lot of pain to save CPU cycles by avoiding a full handshake. When a client browses a website, (s)he will initiate many connections. Beyond the first one (ones with multiplexing?), session reuse kicks in. Repeat that for each client and sum all the saved CPU cycles. Even an improper (non-scientific) benchmark will show you improvement. Session reuse is part of the effort of optimizing TLS trafic to minimize its overhead. Have a talk about it with the W3C webperf group [https://www.w3.org/2010/webperf/](https://www.w3.org/2010/webperf/) if you wish, to which Ilya G. (participated at nginxconf 2014) belongs. Have a look at his checklist [https://istlsfastyet.com/](https://istlsfastyet.com/) too.​ > Giving the possibility to accomodate with Outlook (and Microsoft products > in general) numerous quirks is fine, but making it the default is debatable… > > I believe this is safe default and clients should not rely on resumed > sessions because > > 1. sessions have timeout defined by server security policy, > 2. and server has limited session storage so old sessions are removed. ​Well, the mechanism behind TLS sessions is basically a trial-and-error​ ​one.​ Even for tickets I would add, if the server changed its Master Key between ticket creation and reuse. There is little-to-no overhead at trying an expired session ID/ticket which the client communicate in his initial message to the server. ID search in cache or ticket invalidation requires few overhead resource and in case of invalidation, normal protocol to initiate a new session resumes. ## There is no guarantee a session exists, but there is everything to gain from it if it does.​ _B. R._ ---
**Author:** ![B.R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/3be4f8/32.png) [@B.R](https://www.ruby-forum.com/u/B.R)\ **Post date:** [March 4, 2016, 11:31am UTC](https://www.ruby-forum.com/t/tls-session-resumption-identifier/244191/9 "2016-03-04T11:31:42Z")
On Fri, Mar 4, 2016 at 11:19 AM, Igor S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Sorry, I meant there is no performance difference between “none” and “off” > settings. ​Well, the client believes he should remember every session ID and store it somewhere for nothing, reading/resending/writing it on every connection. Small enough network traffic difference, though (the extra, useless ID in the ClientHello message could be considered harmless, even though those extra bytes appear on each TLS session establishement). As to default value, builtin session cache was by default initially but it > turned out that > it leads to memory fragmentation. So the default value has been changed to > “off” and > later to “none”. > > Of course shared cache is certainly better as default value but there is > no good understanding > what default cache size should be used. And now it becomes less important > with ticket introduction. ## Total agreement there: I was not pushing for a default activating a cache, but rather for the clean ‘off’ setting.​ _B. R._ ---
**Author:** ![B.R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/3be4f8/32.png) [@B.R](https://www.ruby-forum.com/u/B.R)\ **Post date:** [March 4, 2016, 11:39am UTC](https://www.ruby-forum.com/t/tls-session-resumption-identifier/244191/10 "2016-03-04T11:39:17Z")
On 04 Mar 2016, at 13:30, B.R. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > On Fri, Mar 4, 2016 at 11:19 AM, Igor S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Sorry, I meant there is no performance difference between “none” and “off” > settings. > > ​Well, the client believes he should remember every session ID and store it > somewhere for nothing, reading/resending/writing it on every connection. > Small enough network traffic difference, though (the extra, useless ID in the > ClientHello message could be considered harmless, even though those extra bytes > appear on each TLS session establishment). I believe this is negligible degradation for a client. These operations can be only noticeable on server which serves a lot of simultaneous clients.