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

Improve this question

1 Answer 1

Reset to default
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.

Improve this answer
7
  • 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, 2014 at 10:58
  • @MichaelKjörling relevant
    – Bob
    May 31, 2014 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, 2014 at 19:20
  • 1
    @Bob And when was the last time you manually confirmed the certificate fingerprint on every single request?
    – user
    May 31, 2014 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, 2014 at 21:07

You must log in to answer this question.

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