SSL: How are certificates protected against man in the middle attacks?

views:

answers:

+1 Q:

SSL: How are certificates protected against man in the middle attacks?

My question is about certificates specifically in ssl but I think the questions should apply to all certificates. I have included the SSL procedure for the sake of clarity.

In SSL this is what I understand to be the procedure:

1)Client

sends supported crypto algorithms
sends client nonce

2) Server

chooses (and sends) a
- symmetric algorithm
- a public key algorithm
- a MAC algorithm
sends it's certificate
sends server nonce

3) Client

verifies certificate
- Extracts public key
Generates a pre-master secret key (pms)
encrypts with servers public key and sends

4) Client and Server

compute master secrete (MS) from PMS and nonces
PMS sliced to generate two encryption & two mac keys

5) Client

sends a mac of all handshakes (to ensure they were not previously modifide)

6) Server

sends a mac of all handshakes

Question

What stops a man in the middle attack from happening at step two? Why can't a man in the middle, say trudy, capture the certificate sent by the server and change the public key in it (to something it has the private key to).

I assume that the certificate is encrypted somehow.

However the server cannot encrypt the certificate because the client does not have the public key yet. When the server gets the key from an authority (like veri-sign) would the key be pre-incripted using verisign's public key? I think this should work because all web browsers should have the public keys of most authorities.

+2 A:

Certificates are signed by some trusted authority, such as Verisign.

The certificates for these root authorities are built right into the browsers when you download them. You can view the root certificates in Firefox, for example, by going to tools-->options-->advanced-->encryption-->view certificates-->authorities.

If any one of these root-certificate authorities is compromised, however, you are right that a certificate could be forged, making a man-in-the-middle attack possible.

BlueRaja - Danny Pflughoeft 2010-01-21 14:10:58

Just to elaborate on the process: If you want a certificate signed by, say, Verisign, you have to prove to them you have the associated private key (by signing something for them), and that you own the domain in question. Typically, this involves just responding to an email at that domain, but it is *much* more involved (requiring you to physically go to their building and provide several forms of identification) for EV certs (http://en.wikipedia.org/wiki/Extended_Validation_Certificate)

BlueRaja - Danny Pflughoeft 2010-01-21 14:15:15

...and that's the reason, why CACert has such a bad time, unfortunately.

Boldewyn 2010-01-21 14:17:32

+3 A:

No, the certificate is not encrypted. But it is signed by a certification authority (CA). Since those check the information included in the certificate (especially the URL to which the cert belongs), there shouldn't be a second valid certificate for a given URL.

The cert of the CA is checked against a trust store (e.g. in your browser). If this truststore is compromised, or if you trust not valid certificates, there is no protection against man in the middle attacks

Jens Schauder 2010-01-21 14:12:04

So what prevents Tudy (a maninmiddle) from changing the information in a certificate but leaving the same signature? Is the signature somehow a hash of the information in the certificate? How does the signature ensure that the certificate is secure?

sixtyfootersdude 2010-01-21 14:23:15

@sixtyfootersdude You are exactly right. The cert is basically some piece of content (public key of someone, the url for which it belongs ...) + a hash of that content encrypted with the private key of the CA. So everybody can decrypt the hash and compare it to the acutal hash. But someone changing the content can't recreate the encrypted hash.

Jens Schauder 2010-01-21 14:28:54

A hash is taken of the certificate. This hash is then encrypted with the private key of the CA. To verify, the same hash is computed by the verifier and the signature is decrypted with the public key of the CA and the two hashes compared.

Vatine 2010-01-21 14:29:07

@sixtyfooter: yes, that's exactly what it is. Signatures are typically a hash (or hash-of-a-hash) which is then encrypted using the authority's **private** key. Then, anyone can decrypt it using the authority's **public** key and verify the hash, but no one can forge it without knowledge of the private key.

BlueRaja - Danny Pflughoeft 2010-01-21 14:29:19

+1 A:

You actually pointed out a weak spot of PKI.

Say Trudy is in the middle of you and yourbank (bank.com). Trudy can change the public key at will at step 2 but the certificate's signature will be invalid. So Trudy has to find a way to generate the signature again. It's safe to say that the trusted CAs will not do this for him. So he has to sign with a fake CA, which is not trusted by your browser. This is still safe theoretically.

However, most browsers (especially IE 6) display a vague security warning and most people don't understand and just ignore, according to some tests.

ZZ Coder 2010-01-21 14:33:56

Huh, seems like an interesting scam. I bet for most things people don't pay attention to those vague (and technical) warnings. But I would suspect that for banking and things like that people are more careful. I wonder if it would be possible to have a clearer warning..

sixtyfootersdude 2010-01-21 14:39:55

Experience has shown the only solution is to disallow the connection. No matter how clear the warning, the user will click through. I remember a hilarious example with where a Message Box pops up, with title "Virus Warning", the content of the box was "This is a virus, do you want to continue" with two boxes, each of which says "Yes".

GregS 2010-01-22 03:13:54

ansaurus

tags:

views:

answers:

SSL: How are certificates protected against man in the middle attacks?

related questions