[gnutls-devel] Bug: SNI is ignored when resuming session from cache

Nikos Mavrogiannopoulos nmav at gnutls.org
Mon Sep 18 07:53:13 CEST 2017

On Fri, Sep 15, 2017 at 3:41 PM, Thomas Klute
<thomas2.klute at uni-dortmund.de> wrote:
> Hi,
> I have discovered that GnuTLS servers ignore the SNI extension when
> resuming a TLS session from cache (but not when using tickets). The
> function gnutls_server_name_get() always returns
> GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE when called on the resumed
> session, breaking virtual server systems (e.g. virtual hosts with Apache
> and mod_gnutls).
> You can reproduce the issue with gnutls-serv and gnutls-cli (paths from
> dev build):
> ./src/gnutls-serv --x509keyfile=doc/credentials/x509/key-rsa.pem
> --x509certfile=doc/credentials/x509/cert-rsa.pem -p 4433 --sni-hostname
> server.example.com --noticket
> ./src/gnutls-cli --resume --sni server.example.com -p 4433
> --x509cafile=doc/credentials/x509/ca.pem localhost
> The server will warn about the missing server name during resumption:
>   Warning: client did not include SNI extension, using default host
> The proper fix appears to be to reclassify SNI as a "mandatory"
> extension, because if implemented at all it must be parsed on session
> resumption according to RFC 6066, Section 3:
>   "A server that implements this extension MUST NOT accept the request
>   to resume the session if the server_name extension contains a
>   different name."
> The attached one line patch changes the parse type of the Server Name
> extension to GNUTLS_EXT_MANDATORY. For applications that include the
> server name in their session cache handling this fix is sufficient, but
> adding a check to the resumption code might still be reasonable.

Thank you Thomas. That seems like a reasonable fix. Would you like to
send it as a merge request?


More information about the Gnutls-devel mailing list