This whole business has got me wondering if it's even theoretically possible to prevent the site identity being visible to middlemen. Like you said below, even without SNI the cert is sent in the clear, and I can't think of a way around that. You'd need to somehow set up a secure channel before communicating site identity, but encryption without authentication is insecure in the face of MITM, and you need to establish site identity before you can authenticate the server.
I suppose, with IPv6, we could do away with shared-IP virtual hosting, and hence SNI at least; and perhaps we could even devise a system whereby the domain is omitted from the cleartext-transmitted handshake, say by using the IPv6 address as the cert's DN instead... but then that numeric address would serve as a surveillable site identifier, and you can still be tracked.
Is there any active research in this area? Is it provably impossible? Anyone know?
The domain (hostname) you request is inside the encrypted communications between you and the remote server. Only the TCP information is visible (IP, source port, destination IP, and destination port.)
It's the DNS request which reveals the domain you requested.
Have a look at https communication in Wireshark for example. What you wrote is incorrect. Https reveals the domain at least one time these days. First, ssl extension SNI (https://en.m.wikipedia.org/wiki/Server_Name_Indication) is sent, which reveals the domain you're requesting. This happens before the keys are exchanged.
Then, the matching certificate is sent (again in plaintext) from the server so that you can verify it and extract the keys. It will contain the domain again, although it may be a partial one like *.example.com
So no, the domain is public. The full URL path is encrypted though.
