Public-Key Encryption, Certificate Authority, and the Man-In-the-Middle Attack
© 2011,2015 Darel Rex Finley. This complete article, unmodified, may be freely distributed for educational purposes. Not affiliated with VeriSign (Symantec).



View the Vietnamese translation of this page, courtesy of Anh K. Huynh.

(Note: This discussion probably is not a description of the exact methods used by HTTPS servers and VeriSign. It’s merely intended to illustrate the general issue of public-key encryption, the man-in-the-middle attack, and how man-in-the-middle can be defeated by use of a certificate authority.)




Figure 1

In Figure 1, You and Them communicate securely over an insecure network (e.g. the internet) by using ordinary (a.k.a. “symmetric”) encryption. You scramble the data you wish to send to Them using the secret key (red Key) that only You and Them know. Using this same key, you can unscramble the messages They send You. Anyone who intercepts the data in transmission cannot unscramble it for purposes of reading it, and cannot “spoof” (i.e. alter) it.

The problem with this method of encryption is that it requires both You and Them to know the same secret key. What if there are a hundred people with whom you wish to communicate securely? Are you going to have a hundred secret keys? And what if some of these people live far away and you’ve never communicated with them before today — how will you share the secret key in the first place?




Figure 2

The solution to these problems is a system called public-key encryption. (See Figure 2.) You make up a private key (pink A) which you share with no one. You run this private key through an algorithm that turns it into a larger, “public” key (blue A). You share this public key with the whole world in any way you can — post it to your website, append it to your e-mails, add it to libraries of public keys, etc.

When someone wants to send you a secure message, they encrypt their message with your public key (blue A), then you decrypt it with your private key (pink A). When you want to reply, you use their public key (blue B), and they use their private key (pink B) to decrypt your reply.

The nature of the public-key algorithms is such that there is no known practical way to obtain the private key from the public key. The public key is useful only for encrypting a message — then, only the person with the private key can decrypt that message.

When you go to a secure web page (one that begins with “https”, not “http”), before you even see the contents of that page, your web browser and the web site (HTTPS server) first must establish a session key for secure communications while you are visiting the secure (https) portion of their site. It happens like this (see Figure 3):




Figure 3

First, your browser makes up a random private key (pink A). It generates the corresponding public key (blue A), and sends it (with no encryption) to the server.




Figure 4

The server (see Figure 4) creates a random session key (red Key), encrypts that key using the public key (blue A) and sends it to the browser. The browser is able to decrypt it using its private key (pink A), revealing the session key (red Key). Now, the browser and the server both have the session key, and (using ordinary, not public-key, encryption) communicate securely for the rest of the session.

Anyone who spies on this process will not be able to obtain the session key (red Key), and so will not be able to decrypt any of the session communications that are encrypted with it.

However — what if the spy is not only able to look at the communications, but also can alter them in-transit? Then the Man-In-the-Middle attack rears its ugly head. It happens like this (see Figure 5):




Figure 5

Attempting to establish a secure session (as in Figures 3 & 4), your browser makes up a random private key (pink A), generates its corresponding public key (blue A) and attempts to send that public key to the server. The man-in-the-middle (MITM) stops that communication from arriving, and stashes that public key (blue A) for later use. The MITM makes up its own random private key (pink B), generates its corresponding public key (blue B), and sends that public key to the server, making it appear that it came from your browser.




Figure 6

Then (see Figure 6) the server creates a random session key (red Key), encrypts it with the public key (blue B) it thinks it got from your browser. It attempts to send that to your browser, but the MITM intercepts. The MITM decrypts with its private key (pink B), revealing the session key (red Key). It then re-encrypts that session key with the public key (blue A) that it held onto from earlier, and sends it to your browser as if it came from the server. Your browser decrypts it with its private key (pink A), and thinks all is well.

But the MITM has the same session key (red Key), and can now decrypt all communications throughout the entire “secure” session.

So how to stop this? One way is that once the secure session is established, the server and the browser could send each other the public key (blue A) and compare them, to make sure they are identical. But if the MITM knows that the browser and server are programmed to do that, then he can simply change the packets (he has the session key) so that each computer receives what it thinks it should, and neither of them knows that anything is wrong.

To solve this problem, we must bring in the Certificate Authority (see Figure 7). (On the internet, there is a single Certificate Authority, VeriSign.)




Figure 7

When the Certificate Authority first went online (years ago), it created a single, random private key (pink CA), then shared the corresponding public key (blue CA) with the whole world. Browser authors built the public key (blue CA) into their browsers, so it’s already there and doesn’t need to be shared over the network when it’s time to establish a secure session.

When a website owner decides she wants her site to have secure pages, she must create an account with the Certificate Authority (and pay an annual fee, most likely). The Certificate Authority makes up a random ordinary-encryption key just for that site (red H), and sends it to the site owner via FedEx — the site owner installs it on her server. (The Certificate Authority has a unique such key for each secure website on the internet.)

Because the Certificate Authority and the HTTPS server already share an ordinary encryption key (red H), they can send each other messages with absolute security. The MITM cannot read these messages, and cannot spoof (alter) them. The worst he can do is to prevent them from arriving.

Because the browser has the public key (blue CA) already built-in, it can send messages to the Certificate Authority with absolute confidence that the MITM won’t be able to read them — but it’s still possible that the MITM could spoof them, because the MITM has the public key (blue CA), since it is truly public.

So here’s how it’s all used. First, the browser and the server attempt to establish a secure session key just like they did in Figures 3 & 4. When they’re done, they need a reliable way to compare the public key they used (blue A) to ensure that it’s really the same.




Figure 8

The HTTPS server (see Figure 8) encrypts the public key (blue A) with its certificate key (red H) and sends it to the Certificate Authority securely. The browser encrypts the public key (blue A) with its built-in Certificate Authority public key (blue CA) and sends it to the Certificate Authority that way. The browser also sends a new, just-made, random reply key (red R) as part of the same communication.




Figure 9

The Certificate Authority compares the two public keys. Let’s say they match. Then (see Figure 9) the Certificate Authority sends an “all-clear” message to the HTTPS server and to your browser. The all-clear message is sent to the HTTPS server using that server’s certificate key (red H). It is sent to the browser via the reply key (red R) that the browser just made.

At this point, the server and browser begin secure communications. That’s when you see your bank’s login page. By the time you’re typing in your account name and password, secure communications (free of any MITM attack) have already been established.

What happens if the MITM spoofs the browser’s message (in Figure 8), replacing the public key it contains (blue A) with its own (blue B from Figure 5)? That would fool the Certificate Authority into sending the all-clear to the HTTPS server — but when the Certificate Authority tries to send the all-clear to the browser, it will be using some random reply key made up by the MITM. The browser will not be able to decrypt the all-clear message, and since the MITM can’t get the reply key (red R), the browser can’t be made to receive the all-clear message. The browser won’t start the session since it never got the all-clear, and your bank’s login page won’t be displayed.

That’s it! Internet communications secure; Man-In-the-Middle defeated... for a price: Last time I checked, VeriSign (Symantec) wants a minimum of about $400 for just one year. Ouch.


Q: I heard that in 2014 and 2015, Lenovo pre-installed “Superfish” adware on their Windows PCs, which was bypassing SSL altogether but making it appear to the user that HTTPS was functioning normally. How is that possible? Isn’t SSL supposed to make that impossible?

A: SSL (HTTPS) assumes that the three good-guy computers — yours, your bank’s (e.g.), and Verisign’s — are all functioning correctly and making a good-faith effort to establish and use a secure SSL channel. SSL prevents any other computers on the internet (through which your communications may be passing) from violating your security.

However, if your computer happens to be a Superfished Lenovo, then it is very likely not making a good-faith effort to use SSL, but instead is only pretending to do so. Bottom line: If your own computer is compromised, all bets are off — SSL may only look like it’s working!

Q: I’ve heard that when you access the internet in a public place, such as a coffee shop, the shop’s WiFi stations might be rigged to spy on everything you do. Or, another customer’s computer could present its own WiFi as if it belongs to the coffee shop, and you might mistakenly use it. Does that compromise your SSL security, like Superfish?

A: No, it doesn’t. Superfish lives on your computer and can make the browser do things that the browser’s authors never intended. But a spoofed or otherwise compromised WiFi access point cannot make your browser do anything its authors did not intend. Your browser can access HTTPS websites through any intermediate computer — even an intentional spy’s computer — and the spy will not be able to decrypt your communications. As far as SSL is concerned, a fake WiFi access point is just another insecure way-station on the internet, against which SSL is designed to protect you.

Q: I heard that Symantec employees were caught issuing fake certificates for google.com. Could that compromise SSL?

A: Heck, yeah! As mentioned above, if any of the three good-guy computers (of which one is the certificate authority, Verisign, now owned by Symantec) is compromised, SSL may only look like it’s working.


Send me an e-mail!

Back to tutorials.