Establish an enciphered, unauthenticated, connection to an IP.

This is now a tunnel.

Over that tunnel:

* If you've connected before attempt to reuse the cached credentials to further establish a connection to the requested certificate. This validates prior authorization of being the target host.

* If the above fails or if it's a new host, ask for the certificate, perform extensive validation including REQUIRING that the external revocation check authenticates and confirms non-revoked.

How do you create an encrypted connection to an IP address? Just a regular Diffie-Hellman key exchange? That's pretty easy to MitM, and then the attacker can view the certificate the server passes, which will contain the domain name. A little more involved than sniffing SNI, because now you need to scale out MitM-ing instead of DPI, but pretty much the same problem.

Once the connection is MitM'd, the certificate validation would fail, since the MitM host cannot sign the "hash of everything that's been exchanged in this connection so far" with the correct server certificate. So the MitM would have to choose between either learning the domain name but failing the connection, or letting the connection pass but not learning the domain name.

Darn, that right. I guess I fall back to my other answer then: the ISP can always get the domain name from the server ip address and reverse or passive DNS, and there's nothing you can do about that.

I would not use SSL. Why spend time learning and fiddling with something that is so flawed? If I was serious about encrypting traffic I would use CurveCP. SSL is simply a nuisance I tolerate to read the www. Every minute I spend learning about it is wasted time... because I could be spending that time learning about something better, like CurveCP. The spread of SNI has just made SSL even more annoying.

Reading a bit about CurveCP isn't enlightening; it seems to be a UDP protocol that uses elliptic curve cryptography for encryption and authentication. But that, by itself, doesn't explain how it solves the problem that SNI solves better.

Say a client is speaking CurveCP with another party; how do they authenticate the other end? What if the other end has limited resources (such as IPv4 addresses) and needs to serve multiple entities, how do the client and server distinguish or determine which entity to authenticate to/for/with?

I am not suggesting that anyone use something else besides SSL. Use whatever you want to use. I am suggesting that SSL users may want to consider the merits of the SNI extension. Website owners are unlikely to care let alone oppose it.

As a www user, I do not like SNI and that is only an opinion, as a user. Why? Because all existing software that has to be SSL compatible now has to be modified to handle SNI. As a user, I derive no benefit from SNI. That is why I dislike it, first and foremost.

But I believe there may be other reasons to dislike it. Perhaps privacy. Perhaps censorship. Maybe none of the above. I don't know. You decide.

In any event, it seems there are at least a few folks that agree with me that the merits of SNI are at least questionable which is both surprising and encouraging.