How is HTTPS/SSL able to hide destination website that one is connecting to?

Question

I understand how it is able to create a secure connection via the handshake, but how is it able to initiate a secure connection without first sending an unencrypted request, thus revealing the destination website (but not the data sent or received from/to the destination...) to a potential "man in the middle" attacker...? or is it not hiding it?

Answer 1

Don't mistake security with privacy.

The task of SSL/TLS is security, not privacy. This means the data itself are encrypted but meta data like source and destination IP, hostname (with SNI as used by all modern browsers), payload size and timing etc are not. And all these can be used to make a browsing profile of you which includes the sites you visit and sometimes even which pages you visit on the site (based on timing and payload size). But SSL/TLS makes sure that the non-public content (like cookies, form data etc) is protected against sniffing and manipulation.

If you want better privacy you need to combine SSL/TLS with something like Tor, but even this can not guarantee full privacy.

Answer 2

SSL/TLS doesn't hide the source and the destination IP addresses. It is impossible (at least, with a purely ssl/tls solution), because the src/dst addresses must be valid to a working tcp connection.

The name of the connected website, is hidden by default - or, at least, it was until the last some years.

Since then, there is an extension of the TLS named "Server Name Indication", which gives the connected site name unencrypted, yet in the handshake phase.

Man-in-the-middle site is a different thing. With mitm, an attacker can play destination for the client, and play client for the server, using different keys and different ssl/ttls sessions. But it hasn't anything to do with the ssl decryption.

Answer 3

As the other have stated, the initial connection is unsecured and contains IP address at least (though increasingly server name as well thanks to SNI). The destination server responds with a public key certificate and they negotiate the SSL/TLS session.

The key to avoiding man in the middle attacks is the certificate and the fact it's been approved by a certificate authority your browser trusts.

Let's say you have a hacker intercepting communications between a client and a server. The client has asked for a secure connection to the website https://www.example.com (for example). The hacker can send on the request to the real website and relay responses back. The hacker will also be able read the first response back from server to client since that's plain text. However it cannot read the next message from client to server as it is encrypted with the public key of the website and so can only be decrypted with the private key (which the hacker does not have). As these subsequent messages are used to negotiate the key to be used for the actual SSL/TLS connection, the hacker is basically locked out after that first message.

Alternatively, instead of acting like a straight relay, the hacker can give a fake cert (to which it does know the private key) for the client-hacker connection and then it can set up its own hacker-server connection and pass messages between the two. However in this scenario, unless they've managed to compromise one of the main certificate issuers that the client browser automatically accepts, there would be a big red padlock saying the certificate the hacker sent back to the client is either 1) not real or 2) not for this website.

Most MITM attacks depend on keeping the connection on standard http. For example you go to www.mybank.com (so the browser tries http:// by default as you haven't specified a protocol). The bank would normally redirect you to https://www.mybank.com but instead the hacker intercepts that redirect and keeps you on http for the client-hacker connection but sets up a proper https connection from hacker to server. In this scenario the hacker hopes users don't notice that there's no green padlock and they haven't switched to https. Hackers are pretty much out of luck if the user goes straight to https.