Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 7 Aug 2021 02:50:16 +0000 (UTC)
From: Thorsten Glaser <>
To: Axel Beckert <>
Subject: SNI is a security vulnerability all by itself (was Re: [Lynx-dev]
 bug in Lynx' SSL certificate validation -> leaks password in clear text via
 SNI (under some circumstances))

>Axel Beckert dixit:

>>IMHO this nevertheless needs a CVE-ID.

I wonder… perhaps the use of SNI, both in the TLSv1.3 standard
and in some TLSv1.2 implementations, should receive CVEs as well?

It certainly ought to be disabled by default. Perhaps add some
environment variable to enable SNI in the SSL library, and if
it’s not present or explicitly set to 0, disable SNI (which also
would disable TLSv1.3 as it requires SNI). Hmm, yes, this sounds
completely like a good idea.

(Considering SNI also leaks the vhost addressed by the end user,
which is otherwise hidden with wildcard certificates or grouped
with tone others in multi-subjectAltName certificates, it ought
to have been anyway.)

“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
	-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.