7

According to process of authenticating a server certificate:

enter image description here

What's keeping a malicious server to fill up a valid server certificate since it knows all the things:

  • Forged Server public key (man in the middle public key instead of actual server public key)
  • Certificate serial number. (actual server)
  • certificate validity period (actual server)
  • Server's DN (actual server ... but we are sitting in the middle of the IP route)
  • Isser's DN
  • Issuer's Digital Signaure

This question is similar to (How does an SSL server prove its identity?) which deals with step 4, but I am interested in step 3

Community
  • 1
basarat
  • 201
  • 1
  • 6

1 Answers1

17

The "signature" field in a certificate is not a signature in abstracto; it is a signature over the contents of the other fields. You cannot simply copy a signature from a certificate to another one with distinct contents; it will not match. That's the point of digital signatures.

In the case of a MitM, the attacker may put his own public key in lieu of the genuine server's public key, but the client will not be fooled because his signature verification algorithm will tell him that the signature is now invalid. If the attacker wants to succeed, then he needs to obtain a new signature by some CA that the client trusts; and these CA are trusted precisely because they do not sign fake certificates.

Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • 2
    Note that if the MITM is some sort of proxy within a corporation, *its* signing certificate may be installed on clients within that corporation, hence making it possible to successfully impersonate the remote host. The only way to detect that would be to check upstream certs, possibly manually. – user May 31 '14 at 10:58
  • @MichaelKjörling [relevant](https://www.grc.com/fingerprints.htm) – Bob May 31 '14 at 12:07
  • @MichaelKjörling correct. If the MITM is a CA (hint: Google owns a CA, is an ISP in some parts of the USA, and owns the most widely used public DNS servers…) this is easy, otherwise company-internal stuff applies. There _is_ things like CertificatePatrol and MonkeySphere, but they have yet to gain much traction. Just remembering the formerly-used certificates and checking them upon reconnect (like SSH does) helps a bit, but only if your first connection attempt is unintercepted. – mirabilos May 31 '14 at 19:20
  • 1
    @Bob And when was the last time you manually confirmed the certificate fingerprint on every single request? – user May 31 '14 at 20:25
  • @MichaelKjörling I don't see how my own activities have any relevance. I'm simply linking to a resource designed to help detect exactly the kind of attack you are suggesting (MITM by someone who also controls the trusted CAs on the machine you are using). If you really *must* know, I've checked once or twice out of curiosity. I'm not that paranoid. (And the point isn't to check on every request anyway, but to check just once to see if your admins are doing that.) – Bob May 31 '14 at 20:46
  • 1
    The last sentence of your answer is the way things should be, of course, but in practice plenty of CA's have been caught signing fake certificates and they avoid getting removed from browsers/operating-systems by making up some fake apology and promising not to do it again... – R.. GitHub STOP HELPING ICE May 31 '14 at 21:07
  • So the CA private key was used to generate the digital signature and the browser uses the CA public key to verify it? correct? – basarat Jun 07 '14 at 17:31