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.

I had never thought about this situation before, I may be completely wrong but I am going to have to clarify it anyway. When a communication starts with a server, during the client handshake, the client receives a copy of the public key( CA signed). Now, the client has complete access this public key which is signed by the CA.

Why cant an attacker, set up his own server, and use this public key which would essentially make a victim believe that he is the actual server. The attacker of course does not have the private key to de-crypt the communication, but that does not stop the handshake from happening. Since the certificate is signed, when this certificate reaches the victim's browser, its going to say that the cert is indeed fine.

What am I missing here ?

share|improve this question

7 Answers 7

up vote 15 down vote accepted

The handshake includes these (rough) steps:

  1. The server sends its public key.
  2. The client encrypts setup info with that public key, and sends it back to the server.
  3. The server decrypts the client's submission and uses it to derive a shared secret.
  4. Further steps use that shared secret to set up the actual encryption to be used.

So the answer to your question is, since an imposter can't perform step 3 (since it doesn't have the private key) it can never move on to step 4. It doesn't have the shared secret, so it can't complete the handshake.

share|improve this answer
Perfect answer - for the record, there are cases where spoofing the CA IS possible, but it's a lot harder than just reusing a copy of the CA's certificate - for example, the spoofing of Microsoft's certificates during the Flame attacks - news.cnet.com/8301-10805_3-57446466-75/… - but this is case of pretty savy use of weaknesses in a crypto algorithm that lead to the ability to imitate the MS certificate. In the example above, it was actually a terminal server not a CA, but the attack would work on any type of certificate. –  bethlakshmi Sep 12 '12 at 17:07
@bethlakshmi, this answer is a good simplification of the RSA key exchange, but (EC)DHE cipher suites are also increasingly used: the client doesn't encrypt with the server's public key there. –  Bruno Sep 12 '12 at 17:43

As it turns out, I asked this question in 2012, but now in 2015, there is actually an attack that makes this possible. Depending on the implementation, clients can be vulnerable to this attack which can allow an attacker, a MiTM to spoof any signed certificate that he wants.

https://www.smacktls.com/ provides an in depth explanation of how this works because of bad implementation of the SSL state machine on the client.

share|improve this answer

The answer as to why you cant simply take the signed public key and use it to intercept traffic in a man-in-the-middle style attack is that you (or the attacker) wont have the corresponding private key that goes with the public key.

So the browser will receive the web servers or the CAs signed public key, and will use that to encrypt its own secret to send back to the web server.

The web server has the corresponding private key needed to decrypt the data sent back by the browser that was encrypted with the public key, the attacker doesnt, so they wont be able to decrypt the traffic.

share|improve this answer

The existing answers talk about encrypting with the certificate's public key, which isn't always what's actually used (in particular with DSA or DHE cipher suites). (There's an answer with more details here, for example.)

The immediate purpose of the SSL/TLS handshake is to establish a share pre-master secret between the client and the server. This pre-master secret is then derived into a master secret and then into encryption keys (and MAC). This procedure is more broadly referred to as the key-exchange (see RFC 4346 Appendix F.1.1).

To make sure you're communicating with the right party, you need to use a cipher suite that supports authenticated key exchange. (Anonymous cipher suites are disabled by default in sensible configurations.)

This authenticated key exchange falls in two categories:

  • RSA key exchange (e.g. TLS_RSA_WITH_AES_128_CBC_SHA): the client encrypts the pre-master secret using the server's public key (found in the certificate). Only the legitimate server can decipher this with its private key.

  • DHE key exchange (e.g. TLS_DHE_RSA_WITH_AES_256_CBC_SHA or cipher suites with a DSS certificate): a Diffie-Hellman key exchange takes place. It's usually Ephemeral DH, the variant with fixed parameters (DH, not DHE) is very rare. (Having an RSA-based certificate doesn't imply an RSA key exchange.) The server signs its DH parameters and the client verifies the signature against the public key in the server certificate. Since only the legitimate server was able to sign with its private key, the exchange is authenticated.

One method uses encryption, the other uses digital signature, both using the public key in the certificate. Both have the same end result: a pre-master secret that the client can share exclusively with the server that has the private key for its certificate.

(Of course, the other point is that the client must verify that it trusts the certificate to be valid and issued to the server it wants to communicate with, but these are slightly separate points.)

share|improve this answer

Asudhak, don't feel bad if this is a bit confusing. Inventing asymmetric cryptography was a huge advance in Mathematics. It seems very counter-intuitive if not down right impossible when one first encounters it.

When a client (often a web browser) and a server (often a web browser) want to establish a secure communications channel they perform what is called a 'key exchange'.

The public key that the server provides to the client program contains nothing secret. It's only function is to encrypt information.

The client generates a one time secret password that only the web browser knows. The client then uses the server's public key to encrypt that one time use secret password. The public key can only encrypt, the public key can not decrypt!

The client can safely transmit this encrypted secret password to the server. Any man-in-the-middle who might intercept this key exchange will gain no useful information since he almost certainly can't decrypt that one time use secret generated by the client and encrypted with the server's public key.

The server, and only the server has the corresponding private key. The server's private key can only be used to decrypt. The server's private key is never transmitted to anybody!

The server uses the private key to decrypt the one time secret password that was generated by the client (web browser).

The client and the server now both know a secret that nobody else knows!

Using this secret they can encrypt their subsequent conversations using any traditional symmetric encryption algorithm with a high degree of confidence that the channel is secure.

In addition, the client has a store of 'certificates' that contain the public keys of organizations that it trusts. The actual TLS key exchanges will fail if the server doesn't present a digital document called a certificate that contains a hash value encrypted with the trusted organization's private key. The client can use this hash and the trusted public key to know that this server is considered trustworthy.

share|improve this answer
Well technically the public key can "decrypt" what is encrypted with the private key, but this function is generally only used for signing. (ie, a way for the server to verify it holds the private key) This is important because it is how CAs work. They sign the public key of the server with their private key such that the client can use the public key they have on file for the CA in order to validate that the public key did in fact come from the CA. (And thus that hopefully the CA verified that the server is who they claim to be). –  AJ Henderson Sep 13 '12 at 18:48

That the CA certificate (public key) for verified certificates is already included in the browser and that your scenario would generate an SSL warning.

If you are talking about something along the lines of SSH, you will still need to accept the public key. If you don't verify that that key is correct through another secure channel then it is your own fault if you get MITM'ed.

share|improve this answer
Since I am simply taking the Certificate from the actual server itself, and presenting it to the victim's browser, how will the browser claim it to be invalid ? What changes ? –  sudhacker Sep 11 '12 at 18:57
the certificate is hard coded within the browser, it never gets pulled of a server, hence you cannot spoof it. –  Lucas Kauffman Sep 11 '12 at 18:59
I believe using openSSL, you can indeed pull server certificates : fdmanana.wordpress.com/2008/07/01/… –  sudhacker Sep 11 '12 at 19:01
Yes and that will generate an SSL warning. –  Lucas Kauffman Sep 11 '12 at 19:02
@LucasKauffman, asudhak is talking about the Server's signed public key certificate, which is indeed something he could grab from a client. I think you're referring to the Certificate Authorities' signing certificate, which is stored within the browser's key store, and which is used to verify that the certificate the server sends was validated by a legitimate CA. –  gowenfawr Sep 11 '12 at 19:04

You wouldn't be able to finish the TLS handshake as the client takes the servers public certificate and uses it to encrypt a PreMasterSecret that is used to generate the Master Secret.

The client responds with a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public key of the server certificate.

The client and server then use the random numbers and PreMasterSecret to compute a common secret, called the "master secret". All other key data for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed pseudorandom function.

Remember, in asymmetric cryptography the public key is not by any means a secret and in general (assuming no other flaws) is of no use to an attacker.

share|improve this answer
Yes, but the public certificate is what the attacker has. Which means the TLS can still complete right ? –  sudhacker Sep 11 '12 at 18:59
@asudhak - The public certificate is of no use. The private key is needed to decrypt traffic from the client to complete the handshake. If the attacker cannot decrypt the traffic because they use someone else's public key the TLS handshake fails and the browser gives a warning. –  dr jimbob Sep 11 '12 at 19:05
@drjimbob I'm interested to see how it looks like in a browser when the TLS handshake fails. –  supertonsky Jan 27 at 10:50

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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