An SSL/TLS Misunderstanding

Question

I have a fundamental misunderstanding of SSL/TLS that I am hoping can be cleared up.

The way I understand it, when I get a certificate for my site it has all of my information and is signed by my certificate authority (VeriSign, or whomever). When someone requests a page from my site that uses SSL/TLS, the certificate goes to the user and it is validated using the certificate authority's well known public key. Then the user can look at the cert and see my information. They are confident that I am who I say I am and that the message hasn't been tampered with since the validation worked correctly.

What is to stop me from putting a proxy in the middle of the browser and the real site and just sending the real site's certificate (which, and I have no idea if this is right, I assume I have at this point since my browser pulled it down to verify it) to the client and making the client think that it is really site whateverdomain.com when it is really me in the middle?

Thanks.

Answer 1

The oither answers are essentially correct as far as how SSL/TLS work and the certificate exchange. But let's look at this specifically as it relates to your original question.

In order for this to work, the proxy server must be able to:

1. Present a certificate where the Common Name attribute matches the site domain to which you want to connect. In other words, if you wanted to go to https://www.example.com, the proxy server must be able to present a certificate with www.example.com or *.example.com as the Common Name.
2. The certificate presented by the proxy must have been signed by a CA that your browser trusts. Although your browser trusts dozens of CAs, theoretically none of them will issue a certificate with the Common Name www.example.com unless you can prove that you own that domain.

So in practice, it is very difficult to get a proxy server to impersonate SSL/TLS sessions outside of a corporate environment. Inside the corporate environment, this is a different story. Corporations routinely enroll their own internal CA certificate in the browser on your desktop. When you sign on to your bank with TLS it is very common that the corporate web proxy will generate a certificate on the fly with the proper domain name to present to your browser. Your browser sees https://www.mybank.com and a matching certificate from a trusted CA and is happy. Meanwhile the corporate web proxy maintains a separate TLS session to your bank. In between, the proxy has the ability to log all of your HTTPS post and get calls, including contents of any forms such as ID and password.

Outside the corporate environment, most attackers don't need to go to that much trouble since they can sit in a Wi-Fi hotspot and run SSLStrip. Most people won't notice the session is not actually SSL, especially when the attacker changes the favicon to a lock symbol.

Answer 2

The certificate only contains the public key for the SSL connection. The client will communicate to the server using the public key in the certificate, so the proxy would need the associated private key, which is kept secret.

Note that the public/private key pair are typically used to exchange a symmetric encryption key which is used for the bulk of communication.

Answer 3

First of all, all of the certificate is public and not encrypted. It is signed, however, with CA's private key.

When the client connects to the server, they perform key exchange based on certain secret information, namely the private key of the server (and the server sends only public certificate without a private key to the client). This was step 1.

Step 2 is for the client to validate the given certificate and ensure that it (the client) has connected to the expected site, i.e. the site has presented the legitimate certificate. Such validation is a complicated procedure (many parameters are checked and many steps are made). Validation involves checking the signature of server's certificate.

Now about MITM attack. In general, it's step 2 that prevents MITM attack. If validation is weak, the attacker can try to forge the certificate and misrepresent the site. Another possible weak place is the CA which has issued a certificate without proper validation or due to security breach (as it happened recently with certain Comodo's sub-CA).

We have a good (I hope :) description of how SSL works in the corresponding article, though it doesn't explain MITM attacks.

Answer 4

First of all, on terminology: When someone encrypts (the hash of) a document with their private key, we no longer call it encrypting - it's called signing. So the certificate authority (CA) signs the (hash of) the document with their private key, so the documents validity can be verified by everyone using the CA's public key.

Second, SSL is now called TLS.

Now, to answer your question: Once you have the public key of the server, you can send messages that only the server can read, because no one else has their private key. So if you encrypt, say, an AES key, and the server sends you back the message "Hello world!" encrypted with that key, you can be sure the message really came from the server, because no one else could have read the key.

The actual handshake in TLS is more complicated than that, but that is the basic idea.

Answer 5

I think that it is easier to explain this without using certificates and then add certificates.

Given that a certificate vouches for a public key, if we remove the certificate you just have the public key. If your site has a public key and you present it to some client, it would have meaning and purpose only if you have the corresponding private key. Otherwise your bluff will be called by the client right away --- the client will pick a random number say 1729, encrypt it using your public key and ask you what the chosen number is. Without the corresponding private key you cannot answer this question and the client will reject you.

All that the certificate from an accepted authority does is to vouch that the website skaz.com's public key is xyz. If we didn't have certificates, then an impostor could create a (public, private) key pair (abc, mno) and tell the world that skaz.com's public key is abc.

To answer your question What is to stop me from putting a proxy in the middle of the browser and the real site and just sending the real site's certificate, which is the classic man-in-the-middle attack, if the random number --- 1729 in this case --- that the client encrypted is used as an encryption key (also known as session key) for all future traffic, then the proxy cannot do anything. For e.g. if the client sends a password encrypted with the session key, the impostor-proxy cannot read it.

In summary, you can send any entity's certificate to anyone but without knowing the corresponding private key it is effectively useless.