[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH8yC8nTm=upoz34jXs5cXnQBTZzQHKx-nUrsacD0=GEUZ9f_g@mail.gmail.com>
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.
