Date: Sat, 7 Aug 2021 12:08:25 -0400 From: Jeffrey Walton <noloader@...il.com> To: oss-security@...ts.openwall.com Cc: Axel Beckert <abe@...ian.org>, lynx-dev@...gnu.org, Debian Security Team <security@...ian.org>, 991971@...s.debian.org Subject: Re: 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)) On Sat, Aug 7, 2021 at 8:29 AM Thorsten Glaser <tg@...bsd.de> wrote: > > >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? As far as I know, the only problem associated with SNI is leaking the server name to a passive adversary in TLS 1.2 and below. TLS 1.3 and above provide for encrypted server names. > 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. If you disable SNI, then you won't be able to setup an encrypted channel. SNI is needed to setup the encrypted channel. During the client_hello, the server needs to know which server/virtual host to route the client_hello to. The user:password@ is for the application layer or HTTP/HTTPS. It should not be present in the transport layer. It is a bug in the application layer, not the transport layer. The transport layer does have a password based authentication scheme, but it is going to be either Thomas Wu's Secure Remote Password (SRP) or Preshared Key (PSK). SRP is based on Diffie-Hellman (something like a^password), while PSK uses a symmetric cipher (something like enc_k(password)). > (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.) Yes, the client will learn the server's IP address. That is not related to SNI. That's just how TLS works under the IETF's threat model. Maybe you are thinking of (or need) something like a Tor hidden service. Transport Layer Security does not provide a guarantee like a hidden service. Wildcards are garbage. You should be wary of an operator that uses them nowadays. A wildcard certificate could be used by an attacker to have you connect to the receptionist's machine in the lobby running a fake site rather than the organization's web server. Jeff
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.