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

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.

  • 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. – a CVn May 31 '14 at 10:58
  • @MichaelKjörling relevant – 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? – a CVn May 31 '14 at 20:25
  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.