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

0 votes
asked Jan 21, 2010 by sixtyfootersdude

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:


  • 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


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.

4 Answers

0 votes
answered Jan 21, 2010 by blueraja-danny-pflug

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.

0 votes
answered Jan 21, 2010 by jens-schauder

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

0 votes
answered Jan 21, 2010 by zz-coder

You actually pointed out a weak spot of PKI.

Say Trudy is in the middle of you and yourbank ( 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.

0 votes
answered Sep 15, 2017 by mohammad-faizan-ali

Here is a very simplified explanation:

Your web browser downloads the web server's certificate, which contains the public key of the web server. This certificate is signed with the private key of a trusted certificate authority.

Your web browser comes installed with the public keys of all of the major certificate authorities. It uses this public key to verify that the web server's certificate was indeed signed by the trusted certificate authority.

The certificate contains the domain name and/or ip address of the web server. Your web browser confirms with the certificate authority that the address listed in the certificate is the one to which it has an open connection.

Your web browser generates a shared symmetric key which will be used to encrypt the HTTP traffic on this connection; this is much more efficient than using public/private key encryption for everything. Your browser encrypts the symmetric key with the public key of the web server then sends it back, thus ensuring that only the web server can decrypt it, since only the web server has its private key.

Note that the certificate authority (CA) is essential to preventing man-in-the-middle attacks. However, even an unsigned certificate will prevent someone from passively listening in on your encrypted traffic, since they have no way to gain access to your shared symmetric key.

It's also worth noting that in addition to purchasing a certificate (as mentioned above), you can also create your own for free; this is referred to as a "self-signed certificate". The difference between a self-signed certificate and one that's purchased is simple: the purchased one has been signed by a Certificate Authority that your browser already knows about. In other words, your browser can easily validate the authenticity of a purchased certificate.

Unfortunately this has led to a common misconception that self-signed certificates are inherently less secure than those sold by commercial CA's like GoDaddy and Verisign, and that you have to live with browser warnings/exceptions if you use them; this is incorrect.

If you securely distribute a self-signed certificate (or CA cert, as bobince suggested) and install it in the browsers that will use your site, it's just as secure as one that's purchased and is not vulnerable to man-in-the-middle attacks and cert forgery. Obviously this means that it's only feasible if only a few people need secure access to your site (e.g., internal apps, personal blogs, etc.).

Welcome to Q&A, where you can ask questions and receive answers from other members of the community.
Website Online Counter