I have heard that a hacker can become a proxy using the router your device is connected to and send his own public key to you instead of you getting the server's public key - which the browser will verify with third parties and they will say this certificate doesn't match the domain, and an SSL error icon will show.

However, what if the hacker also created fake third parties for all certificate authorities and confirmed for your device that yup this is the correct certificate for the domain?


3 Answers 3


Browsers do not accept verification from just any third party; if they did the whole exercise would indeed be pointless. In order to be accepted as valid, the certificate presented by the website must be digitally signed by a trusted certificate authority. The default list of trusted certificate authorities, which you can see in Chrome by going to Settings->Advanced->HTTPS/SSL->Manage Certificates->Trusted Root Certification Authorities, is limited. Getting on this list requires going through an extensive vetting process with browser/OS developers.

Additionally, there is no need for the browser to ever send a request to the certificate authority to verify the certificate. The browser already possesses the public keys of those trusted authorities (in Windows just click View->Details to see it), and a public key is all you need to prove that a certain entity signed a message (which in this case is a certificate). Read up on how digital signatures work if you want to understand the logic behind this. Just like a signature on paper, a digital signature allows you to confirm that an entity has approved of something without actually having to contact that entity.

  • 1
    "Additionally, there is no need for the browser to ever send a request to the certificate authority to verify the certificate" - halfway true, don't forget certificate revocation Commented Jun 14, 2016 at 0:08
  • 2
    @MathiasR.Jessen a) how many things actually do revocation checks? b) when Chrome does them, it doesn't contact the certificate authority to do so - scotthelme.co.uk/certificate-revocation-google-chrome Commented Jun 14, 2016 at 0:29
  • 3
    Caution: Chrome on Windows, and IE/Edge (but not Firefox), uses the Windows certstore, and the list you see is not definitive; since about 2008 Windows will on-demand add new roots from a trust list controlled by Microsoft (but not the MitM/hacker). See security.stackexchange.com/questions/81491/… security.stackexchange.com/questions/15688/… . @TessellatingHeckler Firefox and IE definitely do OCSP, and I'm pretty sure IE does CRL if needed but I haven't seen it needed in a long time. Commented Jun 14, 2016 at 7:15

The way certificates work is that a certificate is sent by the web site to your computer. Your browser reads the certificate, looking for the identity of the "signing certificate." It then validates the signature of the downloaded certificate was created by the signing certificate. If the signing certificate is signed by itself, it is called a trusted root certificate. But not any old trusted root certificate will do. The browser will only trust certificates it was configured to accept when you installed the browser. These specially trusted certificates make up your trusted root certificate store, and can be OS based (Windows has a Certificate Store used by Edge, IE and Chrome browsers), or browser based (Firefox comes with its own pre-installed list of trusted root authorities.)

The attacker would have to first inject a trusted root certificate into your OS's Trusted Root Certificate store or your browser's list of trusted authorities.

Trusted authorities aren't looked up dynamically from the web while browsing. The proxy would never handle the trusted certificates except as a part of the installation package; and if the installation package was modified by the proxy, the package's signature would fail and the OS should give you an "unsigned package" warning when you're installing it.


You are correct on your first statement. Unless s/he is a trusted CA, your browser will still bitch that the cert is not trusted. And you'll know you're being MiTM'd.

For the second paragraph, you're reaching a bit.The hacker would have to compromise DNS for ALL CAs and have a way to validate the bogus certs. Highly unlikely.

  • hacker is in control of network, why can't he also pretend to be DNS provider Commented Jun 13, 2016 at 20:01
  • then he can redirect verification request to himself to which he would say yes Commented Jun 13, 2016 at 20:03
  • 6
    @MuhammadUmer there is a cryptographic validation done of the CA cert, and that cert must be in a database that is on the client computer. If an attacker can modify that database, then they win. Otherwise, the forgery will be detected and you'll get a pop up confirmation dialog Commented Jun 13, 2016 at 21:19
  • @NeilSmithline just echo'd what I said.. the DNS part isn't the issue.. the cryptochallenge from the real CA is. Thanks Neil
    – HashHazard
    Commented Jun 13, 2016 at 22:39

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