4 ms·

"First your website uses SNI..." s/uses/may use/ Not every website uses SNI. For example, the majority of sites linked to from HN do not use SNI. Also, ther

"First your website uses SNI..." s/uses/may use/ Not every website uses SNI. For example, the majority of sites linked to from HN do not use SNI. Also, there are workarounds when SNI is not supported. Workarounds have been published by one major corporation who authors a popular web server software and runs a cloud hosting service. Is SNI "the only way to do it"? No. There is another way to do stream encryption for mlutiple websites from one IP. It predates HTTPS. This idea goes back to one of the original authors of the world's first web server at CERN. The legacy of this idea survives today as the Websocket "Upgrade" header. Links to further reading below. Because of groupthink dynamics among today's standards committee people and website owners who follow along, it appears that any online discussion of alternative options to SNI is met with swift dismissal. http://www.ietf.org/rfc/rfc2817.txt http://www.ietf.org/rfc/rfc2817.txt http://www.ietf.org/rfc/rfc2818.txt http://www.ietf.org/rfc/rfc2818.txt The draft below refers to proxies but further searching will find papers he wrote about how to start an encrypted stream upon connecting to an HTTP server. Any service could sit behind one simple HTTP interface. This idea was revived in "Upgrade" header referred to above. Then forgotten as HTTPS became popular. Then revived again for "Websockets". http://www.ietf.org/archive/id/draft-luotonen-web-proxy-tunneling-00.txt http://www.ietf.org/archive/id/draft-luotonen-web-proxy-tunn... SNI is not the only solution, it is just one approach, and I suspect the next-generation encryption (a TLS alternative that will be readily adaptable to PQ) will not need to send domain names in the clear.

mappu 9y ago
I am interested in this idea, but I don't expect a better solution than SNI to appear anytime soon. RFC2817's `Upgrade: TLS` is just like SNI except it requires an extra roundtrip and it only works for HTTP, not other TLS-enabled services experiencing the same issue (e.g. IRCS, FTPS, ...). For an HTTPS server with a single certificate and no SNI handling, the domain name is (A) still leaked in plaintext by the initial DNS lookup, and (B) instantly visible by anyone who connects to the IP address. Even if you plug the DNS hole, the fundamental issue is needing to secure communications with the remote server, before you even tell it what domain you're asking for. That can't work under the domain-validation CA model. I suppose you could add an extra layer of indirection, by adding a certificate for the server itself; but that's just moving the chain of trust, and it's practically equivalent to a multi-domain SAN certificate.
super-io 9y ago
Correction: The above draft was not the one I was thinking of. Here it is: http://www.ietf.org/archive/id/draft-luotonen-ssl-tunneling-00.txt http://www.ietf.org/archive/id/draft-luotonen-ssl-tunneling-...

mappu 9y ago

I am interested in this idea, but I don't expect a better solution than SNI to appear anytime soon. RFC2817's `Upgrade: TLS` is just like SNI except it requires an extra roundtrip and it only works for HTTP, not other TLS-enabled services experiencing the same issue (e.g. IRCS, FTPS, ...). For an HTTPS server with a single certificate and no SNI handling, the domain name is (A) still leaked in plaintext by the initial DNS lookup, and (B) instantly visible by anyone who connects to the IP address. Even if you plug the DNS hole, the fundamental issue is needing to secure communications with the remote server, before you even tell it what domain you're asking for. That can't work under the domain-validation CA model. I suppose you could add an extra layer of indirection, by adding a certificate for the server itself; but that's just moving the chain of trust, and it's practically equivalent to a multi-domain SAN certificate.

super-io 9y ago

Correction: The above draft was not the one I was thinking of. Here it is: http://www.ietf.org/archive/id/draft-luotonen-ssl-tunneling-00.txt http://www.ietf.org/archive/id/draft-luotonen-ssl-tunneling-...