Does SNI reveal the virtualhost during the CONNECT query to a HTTPS proxy?

Question

Also, the name of the actual virtualhost is going through unencrypted or not?

Answer 1

The raw answer to your question is: yes, SNI reveals the target host name to the proxy. But, to be more complete:

• As @Steffen indicates, the CONNECT method usually works with host names. The client could ask for a connection with a target IP address, or another host name which happens to resolve (through the DNS) to the same IP address, but clients don't usually do that.

• Once the connection is established, the proxy is supposed to forward all data bytes back and forth, which implies, in particular, that the proxy sees all the bytes. If SNI is used, then the ClientHello handshake message from the client will contain the target server host name.

  One may note, in particular, that a proxy could "delay" the sending. As per the RFC, when the proxy answers to the CONNECT request, it is supposed to have already talked to the target server; but a slightly cheating proxy could claim that the server was contacted, and wait for the client's ClientHello message to do the actual connection. This (theoretically) allows for dispatching requests to different actual servers depending on the target host name.

• In any case, the server will answer with handshake messages of its own, including its Certificate. This is sent, necessarily, prior to any encryption taking place. The server's certificate will contain the server's name (the client verifies it) so, regardless of SNI, the server's name cannot be considered a well-preserved secret.

What is encrypted is whatever is sent after the handshake, i.e. the HTTP headers. But all the proxy stuff happens before, and the SSL handshake itself contains unencrypted data.

---

Now maybe your question is about situations where the connection to the proxy uses SSL, and the enemy is an eavesdropper between the client and the proxy, not the proxy itself. In that case, the enemy won't see the target host name. The enemy will see the SSL handshake, with SNI, between the client and the proxy, and SNI will show the proxy name at that level. Once the tunnel is established, anything that occurs between client and proxy is quite opaque to the adversary (though he will still be able to make a good guess about the size of the data exchanges).

As was pointed out, DNS requests may be revealing. A typical client will first need to resolve the target name to decide whether it is a "local" or "non-local" server, the latter being handled through the proxy. Thus, chances are that the client will first shout the target server name, unencrypted and out of any SSL context. It is probably possible to configure proxying so that such leaks do not occur, but it can take some effort. A more comprehensive proxying solution (VPN, SOCK proxy over SSH...) may be more effective at hiding the names of the sites you browse from your coworkers / fellow students / whatever.

Answer 2

While a CONNECT request could be done with a target IP (e.g. host name resolved by the client) it is usually done with the target host name (and the host name will be resolved by the proxy). The same name is then sent again in clear text within the client hello message when initiating the SSL handshake.