Ssl – Man In The Middle Attacks vs. SSL Certificate Authorities

certificate-authorityman-in-the-middlessl

What stops someone from MITM-attacking the request to the certificate authority to verify the certificate? Does the browser come pre-loaded with the public keys of the trusted certificate authorities (thereby providing authentication)?

Whenever I think about MITM attacks, I think that any defence requires a "safe" connection to be established for authentication, and that the initial establishment of any "safe" connection always seems to be subject to a MITM attack itself. So for example, if the public keys of the trusted certificate authorities above are indeed distributed with the browser, the distribution of the browser would be subject to MITM attacks. As I understand it, even if you physically handed someone a public key / certificate / anything on a piece of paper, you had better know them from elsewhere otherwise they could be a MITM.

Do I understand this correctly?

Thanks!

Best Answer

What stops someone from MITM-attacking the request to the certificate authority to verify the certificate?

When a browser is presented with a certificate by , it doesn't connect to the issuing certificate authority (CA) to verify the certificate; it must already trust the CA, a priori. Depending on the certificate, the CA, and the browser, it may connect to a URL contained in the CA Certificate to check if the cert presented by the site has been revoked (a revocation list), but that connection is secured by the CA cert and not the cert presented by the site. As far as I am aware, most browsers don't actually do this, although most can be configured to. If a CA cert is compromised, then the CA cert will need to either be manually removed, or removed by a patch or new version of the browser code.

Does the browser come pre-loaded with the public keys of the trusted certificate authorities (thereby providing authentication)?

Yes. More than just public keys though, it is actually self-signed certificates from the CAs, which contain public keys, should contain URLs for verifying the Cert itself in addition to Revocation Lists, and potentially much more. Basically, every browser maker has to decide which CAs to pre-install and which ones to leave out, and this is a topic of much discussion and big business. Most CAs generate a lot of money selling certificates, and it benefits them to be pre-installed in every browser, so they push hard on browser makers to install them. But the trustworthiness of the CAs is a topic which can cause much debate among security folks.

Whenever I think about MITM attacks, I think that any defence requires a "safe" connection to be established for authentication, and that the initial establishment of any "safe" connection always seems to be subject to a MITM attack itself. So for example, if the public keys of the trusted certificate authorities above are indeed distributed with the browser, the distribution of the browser would be subject to MITM attacks.

While true, this is a significantly more difficult attack vector than other approaches, and you can combat it by verifying the distribution file of the browser prior to installing it (i.e. verify the SHA1 hash of the installation file based on the published hash of the website). At that point, an attacker would have to infiltrate either the browser manufacturer or the Certificate Authority, which again are more difficult attack vectors (although certainly not unheard of).

As I understand it, even if you physically handed someone a public key / certificate / anything on a piece of paper, you had better know them from elsewhere otherwise they could be a MITM.

Well, giving someone else your public key (or a certificate containing a public key) is harmless. All it means is that they can verify that stuff you signed with said certificate actually came from you (and they could encrypt things that only you can decrypt).

But fundamentally, you are right. At some point, you have to trust someone. That is an important thing to remember about security, networking, business, and life. Of course, you need to temper this with a healthy dose of skepticism, and continually reevaluate your trust relationships. And of course, you should also keep in mind some sage advice from the Gipper: "Trust, but Verify" (or, if you prefer: follow the sound advice of the old Russian proverb: ""doveryai, no proveryai" [Russian: Доверяй, но проверяй]"). To really secure your computer, you will need to power it off, take it apart, destroy the components, then destroy the remains.

As far as establishing a trust relationship with someone else goes, it helps to have a mutual friend that already trusts them. That is the whole point behind the "ring-of-trust" At some point you have to have a little faith. How do you know that the person that issued you your driver's license is REALLY an employee of the state. Of course, you could generate your public key, memorize the fingerprint, and install the pub key on the target system

Do I understand this correctly?

I'm not sure, but I suspect so. Please repeat it all back to me, paraphrased into your own words and I'll let you know.

EDIT: And really, as GregD points out, all this is academic, because most people click the "Proceed anyway" button when their browser warns them that it doesn't trust the cert, and then it is game over. Of course if you work in an enterprise, and control the system that the users are issued, you can probably configure it so it doesn't present them that button, but you will have to deal with the fall-out. The only time it is ever acceptable to click that button is when you are not connected to a network and have single wire between you and the system presenting the untrusted certificate (and even then, it is arguable).

Related Topic