20

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 ?

sudhacker
  • 4,260
  • 5
  • 23
  • 34

8 Answers8

31

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.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • 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 - http://news.cnet.com/8301-10805_3-57446466-75/flame-virus-spread-through-rogue-microsoft-security-certificates/ - 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
  • 1
    Can't someone get the public key and the certificate signature (since they are both available) from step and send it to the client pretending that he's the original website? – Maroun Apr 26 '17 at 13:55
  • 1
    @MarounMaroun they can do that, but the client uses the public key to encrypt something to send back to the server. Since the pretender doesn't have the private key, they can't decrypt that, and the conversation sputters out. – gowenfawr Apr 26 '17 at 14:03
  • 1
    @gowenfawr Thanks. So theoretically, someone can pretend to be the original site, and the browser has no idea about this? I mean, in this case the green padlock will still shows up, correct? – Maroun Apr 26 '17 at 14:09
  • 1
    @MarounMaroun no, you're misunderstanding me. They can start to pretend, but the connection will fail, because you need more than the public key to make it work. Someone can *try* to pretend, but they can't *succeed* – gowenfawr Apr 26 '17 at 14:13
  • 1
    @gowenfawr OK, I'll try to explain more what I'm missing. If someone is standing in the middle, he can actually see **all** the data that's sent from the server to the client. So basically he *can* grab it all, and send it (I know he can't do anything with it because he doesn't have the secret key). But up to this point, is it true that someone can grab all the certificate data while being transferred to the client and "trick" him? Thanks again! – Maroun Apr 26 '17 at 14:18
  • 1
    @MarounMaroun "*is it true that someone can grab all the certificate data while being transferred to the client*? Yes, true. "*and "trick" him?*" No, false. – gowenfawr Apr 26 '17 at 14:25
  • This is really simple, thank you! So many sources I've read say "MitM attacks can be prevented by examining the certificates", but never explained what prevents the attacker from copying the certificates. – Timothy Smith Jun 21 '17 at 19:29
  • I'm thinking on the same lines as @MarounMaroun. The steps you described happens during a handshake between the client and the server. I understand that the imposter cannot decrypt the traffic since he does not have the private key of the server. Does the certificate verification happen prior to this handshake? Or does the certificate verification involve the private key of the server? Could you include certificate validation in your steps – ProgramCpp Sep 06 '17 at 14:55
  • @ProgramCpp the "public key" that I mention is, in fact, the certificate - a certificate is a signed public key. So the certificate validation happens as part of this handshake; after the server hands the client the cert (containing public key), the client verifies the certificate. If it is not verified, the client will not progress to step 2. – gowenfawr Sep 06 '17 at 16:09
  • Does the certificate verification involve a private key? I think without a private key getting involved in the verification, the certificate can be spoofed. i.e, trick the certificate is original. im missing something here. – ProgramCpp Sep 07 '17 at 04:11
  • @ProgramCpp, you're missing how public key ("asymmetric") crypto works. The certificate is a signed copy of the server's public key. "Signed" means that a trusted third party (CA) used their private key to stamp the server's public key and attest that it's owned by who it says it is. That stamp, _created_ with the CA's _private_ key, can only be verified with the matching CA _public_ key - that's the asymmetric part of the equation, one key to "do", but only the other key can "undo", and vice versa. No need, and in fact no use for, anyone's private key in the verification process. – gowenfawr Sep 07 '17 at 04:24
  • My doubt is about the hacker possessing the stamp which is available to anyone visiting the site. If i visit the server, it gives me the certificate with a stamp created using CAs private key. I will now use the same certificate to trick a user. this certificate will be verified good with the CAs public key. – ProgramCpp Sep 07 '17 at 04:43
  • @ProgramCpp BUT you can _never_ decrypt the user's traffic using that public key ("certificate"). You need the private key to decrypt anything encrypted with the public key ("one key to 'do', but only the other key can 'undo'"). So, yes, you steal the certificate, and hand it to the user. Yes, they verify it, it's good. Yes, they encrypt their next traffic with it. And NO, you cannot do anything with that encrypted traffic, because you don't have the private key. – gowenfawr Sep 07 '17 at 04:52
  • So, YES, THEY VERIFY IT IS GOOD. which means certificate verification has passed. My concerm was only about the certificate verification not about decrypting the traffic which is safe without the secret private key. then why do certificate verification? you just present the public key. the client encrypts with public key and only the server decrypts the traffic. what is the need for certificate verification then? Thanks for patiently answering my questions :) – ProgramCpp Sep 07 '17 at 05:13
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/65222/discussion-between-gowenfawr-and-programcpp). – gowenfawr Sep 07 '17 at 06:37
9

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.

Jim In Texas
  • 329
  • 2
  • 3
  • 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
4

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.

Community
  • 1
dr jimbob
  • 38,768
  • 8
  • 92
  • 161
  • 1
    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
  • 2
    @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 '15 at 10:50
3

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

Community
  • 1
Bruno
  • 10,765
  • 1
  • 39
  • 59
2

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

0

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.

Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196
  • 1
    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 : http://fdmanana.wordpress.com/2008/07/01/getting-a-servers-certificate-with-openssl/ – sudhacker Sep 11 '12 at 19:01
  • Yes and that will generate an SSL warning. – Lucas Kauffman Sep 11 '12 at 19:02
  • 1
    @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
  • But that would still generate the same thing no? You would have a public key signed by a CA? If he is talking about SSH then yea it would be possible, but you still need to accept the public key. – Lucas Kauffman Sep 11 '12 at 19:05
0

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.

MaxxVadge
  • 1
  • 1
0

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.

sudhacker
  • 4,260
  • 5
  • 23
  • 34