Sign up ×
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

8 Answers 8

up vote 17 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 -… - 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

This assumes that you know the basics of public key authentication and how a web browser communicates with a web server through a domain name. The interaction is between the user's web browser and the company's web server.

Public Keys and Private Keys

The web server has a public key and a private key. The private key can decrypt a message encrypted by the public key. The public key can decrypt a message encrypted by the private key. The certificate authority has their own public key and private key.

The web server sends its company information, public key, and the domain name (to be associated with the SSL certificate) to the certificate authority. The certificate authority sends a confirmation message to the email address associated with the domain name, in order to prove that this request was made by the genuine owner of the domain name. At this point, the certificate authority will wait until the domain name owner validates the request by email.

Certificate Signing

The certificate authority encrypts the web server's domain name, company info, and public key using their own private key. The certificate authority sends the encrypted result to the web server. This result is the SSL certificate, a text message containing the domain name, company info, and public key of the web server that has all been encrypted with the private key of the certificate authority. The web server sends this certificate to the user's browser.

Trusted Certificate Authorities

The web browser comes pre-loaded with a list of trusted certificate authorities and their public keys. The web browser decrypts the certificate using the public key of the corresponding certificate authority. At this point, the web browser knows that the certificate and its contents are trustworthy because only a message encrypted with the certificate authority's private key could have been coherently decrypted by that certificate authority's public key.

The web browser now knows the trusted company info, public key, and domain name that is supposed to be associated with the web server, which is still suspicious. The web browser confirms that the domain name on the certificate matches the actual domain name of the web server.

At this point, if the domain names match, the web browser determines that the web server is trustworthy enough to send encrypted data to. Also at this point, the web browser determines that it can use the trusted public key of the certificate to encrypt its messages because only the private key of the genuine web server can decrypt that message.

Note that if an untrusted public key was used (not going through the certificate authority verification), the web browser may have encrypted and sent sensitive information only to be decrypted by the private key of a malicious server! In other words, it is imperative that the public key be trusted because encrypting a message with it is the only line of eavesdropping defense for the information that the web browser sends out.

Moving on, the web browser encrypts its message using the trusted public key and sends the encrypted message to the web server. The web server decrypts the message with the genuine private key, if it has one, then reads the decrypted message successfully.

Shared Secret Key

When the web server responds to the web browser, that message must be sent securely as well. The web browser could copy what the web server just did (excluding the certificate authority process) by generating a public key and private key for itself then sending its public key to the web server. This would establish a secure connection called 2-way asymmetric encryption. However, such communication is computationally taxing (relatively speaking).

So the standard approach is to use a shared secret key that can encrypt a message and also decrypt it. The web browser generates a secret key, encrypts it using the trusted public key, then sends it to the web server. If the web server is genuine, it will be able to decrypt the secret key successfully.

At this point, both the web browser and the web server have a shared secret key that they can use to encrypt and decrypt further communications henceforth.

For further reading:

  • Verifying the integrity of the message with hash functions to detect message alterations

  • Chain of trust among certificate authorities

share|improve this answer

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. 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 :… – 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.