On Fri, Mar 10, 2017 at 09:25:41AM +0100, Martin Rex wrote: > > You don't understand the purpose of SNI and how the (already weak) > rfc2818 section 3.1 server endpoint identification and CABrowser Forum > public CA Domain validation has been designed to work.
SNI has extremely little to do with public CA domain validation, except for special validation certificate selection in some methods. Out of 10 standard methods, only 2 would encounter any problems at all if SNI didn't work (test certificate and random value via certificate). And methods using these two presumably both use SNI and don't map it. Certainly, the only known instantiations of "random value via certificate", which are the TLS-SNI validations from ACME specify SNI to be sent. And the values it sends are permanently NXDOMAIN in DNS. And RFC2818 preceedes SNI by about three years, so it can not have been designed to rely on SNI. > Wordpress.com isn't using SNI at all, so the ultimate solution > would be for the client to entirely omit SNI from ClientHello. > > wordpress itself could achieve just the same by using URLs > of the kind > > blogs.wordpress.com/blogname with a cert issued to blogs.wordpress.com > > rather than > > blogname.wordpress.com with a cert issued to *.wordpress.com Nope. That proveds no isolation between blogs. So any way to compromise one would compromise them all. With separate host per blog, you at least avoid the undefendable cross- blog exploits. You still have the cookie exploits, but those can be defended against. And if one adds the base domain to PSL (e.g. like Blogspot (Google)) one doesn't have cookie exploits either. > Btw. your adversary will see the cleartext DNS lookup prior to the > TLS handshake, and tell accesses to multiple different blogs apart by > looking at the size of the responses. DNS over TLS (TCP/853). EDNS0 padding. Both have PS RFCs. -Ilari _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
