Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

This question already has an answer here:

My understanding of how it works :

A victim asks for the public key of a server. The attacker just forwards this request. The server now responds with a certificate which contains the Public key. The attacker modifies this to its own public key and sends it to the victim.

Something happens now that I don't understand:

The browser has public keys of all major certificate authorities. It uses this public key to verify that the web server's certificate was signed by the trusted CA? How? An attacker can fake this request just as it did with the server? Apparently the Browser checks if the certificate is valid? Now how does it go by doing this. The attacker can fake data for this so that the Browser check still result to a True.

If the server's privatekey/publickey changes how would a victims browser know that this is changed?

Then the browser generates a shared symmetric key and encrypts it with the attackers key. Therefore the attacker can decrypt it. Get the key. Encrypt it with the servers key and send it off to the server.

share|improve this question
    
Previous question on SO –  CodesInChaos Nov 24 '13 at 14:15
    
First read How does SSL work? and all its answers. –  CodesInChaos Nov 24 '13 at 14:16
add comment

marked as duplicate by Terry Chia, Adnan, TildalWave, Xander, NULLZ Nov 24 '13 at 21:45

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

1 Answer

I'm trying not to go into the general workings of public key cryptography as this is described very well at many places:

https://en.wikipedia.org/wiki/Public-key_cryptography https://en.wikipedia.org/wiki/Digital_signature

I suspect the first missing point in your line of thought is that the browser doesn't have to communicate with anybody (putting aside the problem of revocation lists and time sync) to verify a certificate as long as it has the certificate and the public keys of the trusted CAs - this is why public-key crypto is great! It just has to calculate hash of the contents of the certificate and decrypt the signature using the CAs public key: if the decrypted value and the calculated hash match, the certificate is trusted (this is a highly simplified version of the operation though).

At this point the attacker faces the following hard problems:

  • He can't intercept/modify traffic secured via the servers keypair, because he doesn't know the servers private key.
  • He can't replace the servers public key contained in the certificate, because this will break the signature.
  • He can't just sign a certificate containing his public key because the browser doesn't know the public part of his signing key (the attacker is not trusted by the browser).
  • We hope that the attacker couldn't obtain a CA key.

If the servers public key changes a new certificate with the new public key has to be created - the client will receive a different certificate and that's basically it.

share|improve this answer
add comment

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