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

Thomas Klute thomas2.klute at uni-dortmund.de
Fri Sep 15 15:41:53 CEST 2017


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.

Best regards,
Thomas Klute

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sni_ext_parse_mandatory.diff
Type: text/x-patch
Size: 523 bytes
Desc: not available
URL: </pipermail/attachments/20170915/7d56b993/attachment.bin>

More information about the Gnutls-devel mailing list