Is Spoofing a CA signed certificate possible?

Question

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 ?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.)