Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3

Hi, Ralf.

I'm not disagreeing with you regarding 1.3. At least in the long version of the handshake (which you should be able to enable in any browser, if you want a little more privacy in exchange for an extra roundtrip).

But ordinarily, the sites that can get you killed are not collocated with benign sites. And even when sites are collocated, the servers demux not based on the SNI parameter in the TLS handshake, but based on the Server header in HTTP. The only use of the SNI parameter is for selecting the right certificate. So if you try to go to https://www.gmail.com , you get a certificate for www.gmail.com<http://www.gmail.com> , before being redirected to the same server, but this time with the URI https://mail.google.com .

It would be much nicer if we could update HTTPS (RFC 2818) to support this kind of multi-homing so as to make SNI superfluous. For example, if the server certificate could list the different domain names that it was valid for. Yes, I know there's an economic side to this as well. I'm sure the CAs could charge by alternate name if needed.

Yoav

On Nov 7, 2013, at 9:03 AM, Ralf Skyper Kaiser <skyper@thc.org<mailto:skyper@thc.org>> wrote:

On Thu, Nov 7, 2013 at 4:39 PM, Watson Ladd <watsonbladd@gmail.com<mailto:watsonbladd@gmail.com>> wrote:
On Thu, Nov 7, 2013 at 8:32 AM, Ralf Skyper Kaiser <skyper@thc.org<mailto:skyper@thc.org>> wrote:
>
>
> 1. Meta-data is important. Meta-data tells a lot about a person.
> Meta-data can get a user killed or worse. Transmitting the host-name
> (meta-data) in clear in TLS is not good (as in ‘not good because it
> can get you killed’ and there is no alternative for the user – unless
> the user is a tech-wizard.).
They can use Tor. They need to anyway: reverse DNS lookups are not
rocket science.

[...]

>
> There are other ways how an adversary can extract the same meta-data.
> This should not deter us from fixing it in TLS. Maybe we will find a
> solution for the other problems as well (like confidential DNS).
No, the other problem is you connect to the server and ask it to show
you a page,
and learn what the server is. The sole exception is multihosting,
which is getting
less common for various reasons.

As a hacker I would love TLS to leak the host information. It would enable me
to find out which user connects to admin.blubb.com<http://admin.blubb.com/> and who connects just to
www.blubb.com<http://www.blubb.com/> (both domains hosted on same server).

Your comments are wrong in this scenario: Connecting to the server does not help
the hacker to gain above information. Neither does reverse lookup.

TLS leaks it and there is no other way the hacker would get this information if
TLS would not leak it. Transport Layer Kind-off-Security protocol is the problem.

regards,

ralf

_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls