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

Question

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 the procedure is:

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-encrypted using verisign's public key? I think this should work because all web browsers should have the public keys of most authorities.

Answer 1

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