[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
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.
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