On 12/2/15, Martin Rex <m...@sap.com> wrote: > Jacob Appelbaum wrote: >> On 12/2/15, Martin Rex <m...@sap.com> wrote: >>> >>> So your client will have to know a-priori, out-of-band or be configured >>> to TLSv1.3-only in order to avoid using a TLSv1.2-compatible ClientHello >>> with cleartext SNI. >> >> I think that is false. One could easily use the "cleartext" SNI field >> and insert an encrypted value. A hash of the name would be a simple >> example but not a secure example, of course. > > No you can NOT do this (in TLSv1.2 and earlier), because it is entirely > backwards-incompatible.
If I configure a vhost to respond to a sha1(example.com) and have a way to visit sha1(example.com) in a browser, I think it doesn't even break the spec. That doesn't really matter - the point was to suggest that there are many ways to solve this problem. Assuming a shared key, we can easily take a field and transform it. There are compelling reasons to do it and there are active attackers who are exploiting the lack of confidentiality in TLS. > > Server-side SNI can even be implemented completely outside of the TLS > protocol stack (that is how I implemented it). I'm curious - are you saying that if the value was encrypted... it would become impossible to implement it outside of the TLS protocol stack? Or is this just an aside? > >> >> To the point about TLS 1.2 vs TLS 1.3: Legacy clients will be less >> secure > > That is a myth. Are you asserting that TLS 1.3 will be less secure or equally secure here? >> >> and in ways that will only become worse over time. We should >> remember that TLS 1.3, while not yet finished or deployed, is a future >> legacy protocol. > > TLSv1.3 is looking more and more like a future market failure to me, > worse than IPv6. Without privacy on the internet, I'll see your market and raise you a TCP RST. All the best, Jacob _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
