12

I understand that Digital Certificates and Certificate Authorities (trusted 3rd parties) help prevent man in the middle attacks during HTTPS connections. However, I am confused on a few details.

Let's say we have a client Alice and Bob who has a server mapped to "bob.com".

When Bob (bob.com) asks a CA (let's say veriSign) for a new certificate to be created and sends them his public key to be put inside the certificate, what is stopping a hacker from intercepting the request, switching the public key with their own, having the CA create a false certificate, and then returning this false certificate to Bob. Is the only protection here that Bob actually checks that the public key on the returned certificate matches what he originally sent in his request to the CA? And then I guess informing the CA that what he got back doesn't match what he sent out, so the CA doesn't maintain a false record?

Assuming that the newly created certificate Bob gets from veriSign is legit, let now say that Alice is going to make a request to "bob.com" via the HTTPS protocol. What is preventing a dual channel MITM attack where a hacker intercepts Bob's new certificate on way to Alice, creates a new one, signs it with their own secret key (which was previously signed by verisign), but then also intercepts Alice's request to veriSign when she asks for veriSign's public key, and switches it out again with the matching public key to the malicious secret key. Now when Alice tries to check the integrity of the false certificate, it checks out because although she thinks she is checking the signature with veriSign's public key, she is really using the malicious public key?

Improve this question
4
  • 5
    Aside: Verisign is not a good example. They sold their CA businesses (plural) in 2015 to Symantec, which was in the process of gradually rebranding until 2017 they were caught breaking the rules and rather than clean up their act sold the lot to Digicert, who are now more actively phasing out the old Verisign roots. The substance of your Q still applies to other CAs, of course.
    – dave_thompson_085
    Aug 17, 2019 at 3:04
  • 1
    @dave_thompson_085 I think veriSign was supposed to be a general signing company, just like Alice and Bob aren't real names either.
    – Mast
    Aug 17, 2019 at 10:53
  • 1
    You submit your CSR over TLS, so it cannot be modified in usual cases.
    – eckes
    Aug 17, 2019 at 14:51
  • 1
    Why hasn't anyone mentioned that many "trusted CAs" are not actually trustworthy? Just take a look at your computer's pre-installed list (run certmgr.msc) and the certificates that come with your browser. Probably there are hundreds of them. Hopefully you don't have any outright bad certificates (such as Superfish). But many CAs are untrustworthy anyway.
    – user21820
    Aug 18, 2019 at 6:54

3 Answers 3

Reset to default
18

Is the only protection here that Bob actually checks that the public key on the returned certificate matches what he originally sent in his request to the CA?

If the public key was switched before the CA used it to create the certificate, then Bob's web site won't work at all. The private key, which he has kept safe, will only work with his original public key. It is unlikely the attacker can MITM all connections and prevent this fact from becoming obvious.

intercepts Alice's request to veriSign when she asks for veriSign's public key, and switches it out again with the matching public key to the malicious secret key.

Alice doesn't reach out to Verisign; Alice only trusts copies of the CA certificates in her browser or computer's trusted certificate store, of which Verisign's happens to be one.

The trusted certificate store is populated at install time (of the OS, or in the case of Firefox, of the application) and is then updated via regular OS or Application updates as necessary - less than you'd think, as many root CAs are long-lived.

Improve this answer
2
  • IMHO it would improve this otherwise good answer to mention how CA certificates come to be in the trusted certificate store
    – Tom W
    Aug 17, 2019 at 19:44
  • 3
    @TomW I updated to try and give a simple explanation - if you try to get into the details, say for Windows, it becomes a maze of twisty packages, all different, some causing pulled hair.
    – gowenfawr
    Aug 17, 2019 at 20:13
3

Good question. The certificates of the most trusted CAs are normally included into software install package, e.g. into browser installer, into OS installer, or are preinstalled on device like smartphone. That's why the browser (or some other application) will notice if certificate is really from the specified CA.

Improve this answer
2
  • If browser developers are unable to accurately determine which CAs are trustworthy, why should they be even installed? And even if installing them provides some convenience, why should they be called "trusted"? There is something really wrong with the CA ecosystem, but it seems that few dare to speak up about it.
    – user21820
    Aug 18, 2019 at 7:02
  • 1) Trusted - because the developers of particular software (browser, OS, whatever) trust them. It is up to you to trust or not. You are free to delete any certificates you want. 2) PKI is a complex field. "few dare to speak up" - of course you have right to have your own opinion. But many other people thought about it already 20 years ago (see when IPSEC, DNSSEC, etc. was developed), now even more do that.
    – mentallurg
    Aug 18, 2019 at 13:50
0

You are essentially asking what is stopping a third party from issuing a certificate via a trusted CA.

  1. Cost - CAs charge to issue certificates. It's cost prohibitive to issues thousands this way.

  2. Domain validation - a trusted CA is only trusted because they are trusted to verify domain ownership correctly. Some CAs have failed to do so 100% and have lost their trusted status. One method for validation is an email to the technical contact found on the registrar for the domain. There are known weaknesses here https://en.m.wikipedia.org/wiki/Certificate_authority#Validation_weaknesses

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .