TLS session resumption (identifier)

Igor Sysoev igor at sysoev.ru
Thu Mar 3 15:48:57 UTC 2016


On 03 Mar 2016, at 18:42, B.R. <reallfqq-nginx at yahoo.fr> 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 Sysoev
http://nginx.com

> On Thu, Mar 3, 2016 at 2:29 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> 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>,
> > 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 Dounin
> http://nginx.org/
> 
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160303/f6fd9dd6/attachment.html>


More information about the nginx mailing list