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

[Ryan Hurst <[e-mail]>]

I don’t think the economic issues should be a consideration here, just
whats the right solution.



CAs are already required to include all the domain names in the SAN (
https://www.cabforum.org/Baseline_Requirements_V1.pdf) and all CAs have
models for doing this.



The core issue is that SNI doesn’t require shared keys across parties or
cooperation of any type, using multi-san certificates does. This works in
some cases, for example when the arbitrator (like a CDN) manages that
cooperation but in some cases its not possible for them to.



In such cases they need a dedicated IP or SNI.



Ryan





*From:* [e-mail] [mailto:[e-mail]] *On Behalf Of *Yoav
Nir
*Sent:* Thursday, November 7, 2013 9:30 AM
*To:* Ralf Skyper Kaiser
*Cc:* [e-mail]
*Subject:* 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 , 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 <[e-mail]> wrote:





On Thu, Nov 7, 2013 at 4:39 PM, Watson Ladd <[e-mail]> wrote:

On Thu, Nov 7, 2013 at 8:32 AM, Ralf Skyper Kaiser <[e-mail]> 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 and who connects just to

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
[e-mail]
https://www.ietf.org/mailman/listinfo/tls