TLS session resumption (identifier)

[B.R.]

On Fri, Mar 4, 2016 at 10:33 AM, Igor Sysoev <igor at sysoev.ru> 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/> if you wish, to which Ilya Grigorik
(participated at nginxconf 2014) belongs. Have a look at his checklist
<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.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160304/04d6bda3/attachment.html>