1

I read What's keeping a malicious man in the middle server from forging a valid certificate?, but when the client goes to verify the certificate, can't an attacker intercept that connection and say that the certificate is a valid certificate? Therefore, an attacker can send a forged certificate that the client could not verify. I don't get what would stop an attacker from creating a MITM (Man in the middle).

Community
  • 1
Java Is Cool
  • 165
  • 2
  • 10
  • The verification is on the client side. The attacker can't provide a valid signature for the real server without its private key. – RoraΖ Sep 25 '14 at 15:46
  • @raz No... the attacker can intercept the server's certificate, then generate it's own key pair, and then replace the public key in the certificate. – Java Is Cool Sep 25 '14 at 15:48
  • Yes but then sign it with what? The client uses public keys already stored in its Trusted Certificate Authority store to verify signatures. – RoraΖ Sep 25 '14 at 15:51
  • @raz But when the certificates in the client's Trusted Certificate Authority store expire, how does it update them? – Java Is Cool Sep 25 '14 at 15:55
  • 4
    @JavaIsCool Browser updates and OS updates. [Here's an example](http://support.microsoft.com/kb/931125) of an MSKB hotfix to deploy new root CAs. – Polynomial Sep 25 '14 at 16:02

1 Answers1

2

Not trivially.

What you're talking about is Public Key Infrastructure (PKI). The current implementation of it for SSL/TLS works in a hierarchical trust model. Your browser (and your OS) has a set of Certificate Authority (CA) certificates baked into it, which it trusts. Each certificate contains a CA's public key.

When an SSL certificate is created for a site, their issuing CA signs that cert with their private key. So the public key and details of the site is then signed with the CA's private key.

When you receive the certificate, your browser checks the certificate's signature using the CA's public key, which it has from the pre-installed CA certificates. You can't forge this signature without stealing the CA's private key, breaking the cryptography involved, or finding a bug in the browser's certificate validation code.

The attack you suggested is precisely what tools like Burp Suite can do, but since the generated certificate isn't signed by a trusted CA, the user's browser warns them that the certificate is self-signed.

Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • So you are saying that every year or so, when certificates expire, the client gets new certificates to use for verification? – Java Is Cool Sep 25 '14 at 15:51
  • @JavaIsCool To an extent, yes. Operating systems usually push out updated root CA lists in updates (e.g. Windows hotfixes) and browsers usually ship them with updates. Revocation of compromised or replaced certificates is achieved with Certificate Revocation Lists (CRLs) and similar mechanisms. – Polynomial Sep 25 '14 at 15:53
  • 1
    Trusted root CA certificates generally expire on the order of decades. 25-30 years. Browsers would issue an update to revoke or add new certificates. – RoraΖ Sep 25 '14 at 15:53
  • @raz 10-30 years is a more accurate range. Most are around 20 years, from looking at my TRCA list. – Polynomial Sep 25 '14 at 15:56
  • @Polynomial Guess it depends on the group of certs you look at. I looked at about a dozen for Chrome and they were 25+ – RoraΖ Sep 25 '14 at 16:04