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.
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.