5

So I read something about SSL/TLS and I always don't understand two things. First, why so many of the comments are still saying that just because the attacker doesn't have the private key, a MiM attack after taking the public key wouldn't work. The way I understand this attack, it's all about the attacker posing as the server for the client and the client for the server - the attacker serves as a control center. Correct me where I'm wrong:

  1. The client sends a request to the server
  2. The attacker takes over the client's request
  3. The attacker sends a request to the server himself
  4. The attacker gets the public key from the server
  5. The attacker sends his own public key to the client
  6. A connection is established between the attacker and the client
  7. The attacker sends the client's request to the server in its own encryption
  8. The attacker gets the response from the server and hands it over to the client Voila, MiM attack.

And my second question is, then what is the use of the CA certificate if it can't be verified that it was really sent by the non-attacker who would get it from the server in the attack described above and just use it as his own?

2
  • 1
    It's all about step 5. If the public key that the client receives in this step is not embedded in a certificate signed by a CA that the client's browser trusts, then the client's browser will warn the user that a MITM attack could be underway.
    – mti2935
    Oct 14, 2022 at 15:17
  • "The attacker sends his own public key to the client" and gets rejected.
    – GACy20
    Oct 17, 2022 at 10:14

3 Answers 3

21

Asymmetric encryption does not prevent man-in-the-middle attacks. However, certificates do.

A certificate is a public key tied to an identity. It certifies that this entity owns that public key, and the client can check that this certificate is valid using the chain of trust.

In your scenario, while the attack is possible if people share their public keys, it is not possible anymore when they share their certificates.

Between steps #5 and #6, the client will verify the certificate received, notice that it does not belong to the server and will refuse the connection or present a warning to the user.

If the attacker reuses the server's certificate, the client will accept it, but as soon the client will start to use it to secure the communication, the attacker won't be able to continue as long as they don't have the associated private key. If they do, then MITM is possible - this is why securing the private key is important.

Note that this transfers the risk to the infrastructure that manages the certificates. However, the entity only needs to prove its identity once, under stringent requirements, and can then use the certificate until it needs to be renewed.

9
  • 2
    Of course, when there are many certificate agencies trusted by the client, finding a single corruptible one might not be too hard. Especially if you are a nation level adversary, and one of the CAs belong to your nation. Oct 14, 2022 at 23:43
  • 3
    I did not think it was pertinent to add the thousands threat vectors that could break this system. Trust is a very convoluted concept, especially when the user is unaware of it. Your comment is perfectly right.
    – Yuriko
    Oct 15, 2022 at 0:43
  • I would support an answer complementing mine and stating the limitations to this concept, from the self-signed certificate to the user just paying a W10 license and expecting to browse the internet in a secure fashion "out-of-the-box."
    – Yuriko
    Oct 15, 2022 at 0:49
  • @Yuriko Thank you for this answer, I'm really surprised at your patience for my inexperience. Thank you for confirming that asymmetric encryption is not secure against MITM attack. I am also very thankful for the clarification about the security of the certificate between step 5 and 6. I don't know why I missed this step. Unfortunately, I can't say much about your last comment, but I hope I'll come across this topic at some point and then come back with my help.
    – Koala
    Oct 15, 2022 at 12:00
  • 1
    @Koala: You are welcome. If you judge this answer or another one posted answered your question, could you mark it as accepted?
    – Yuriko
    Oct 15, 2022 at 12:04
9

To answer your second question,

what is the use of the CA certificate if it can't be verified that it was really sent by the non-attacker who would get it from the server in the attack described above and just use it as his own?

But it can be verified. It must be verified, or there would be no trust possible on the internet.

A public key could belong to anybody. But once it's signed by some authority who has validated that it belongs to the entity that presented it, we call it a certificate, and we can trust that the certificate was granted to the rightful owner.

But who are those authorities? How do we know that an authority is really a legitimate trustworthy Certificate Authority (CA)? How do we know they check that certificate requests are legitimate? By a series of agreements, and the CA's adherence to strict standards of behavior and security. The CA/Browser Forum is the group that writes the standards that all registered CAs must follow.

(If a CA is ever caught issuing certificates to untrustworthy parties, the penalties are severe. Their certificates will be revoked and they will literally be kicked out of the CA business. Look up the "DigiNotar" entry in Wikipedia for a spectacular example from about 10 years ago.)

These CAs are different kinds of businesses and government agencies. Digicert is a private company that issues certs, and that's all they do. Microsoft has a CA, as does Apple, Google, and some other tech firms. There are various telecom companies included, and representation from many companies and countries around the world.

So now we have a group of CAs that have pledged to follow the rules, and they have been deemed "trustworthy" by various auditors. The root certificates issued by those CAs are then collected and included by various OS publishers and browser publishers as part of their software installations. Your OS probably has about 200 trusted root certificates in it belonging to these CAs. Some browsers, languages, and other software packages will also often include their own list of CAs. Whatever the source, they're already installed in your computer.

When StackExchange needed a new certificate, they set up an account with their CA, Let's Encrypt. In their registration they said "we want a certificate for stackexchange.com", and they created a Certificate Signing Request (CSR). Let's Encrypt then said "before we sign it, you have to prove it's really you. Here's a secret random number to put on your web site at stackexchange.com, and we're going to check for it." So Stack Exchange hosted a page with that number, and Let's Encrypt made sure that DNS routed their request to right server, and retrieved the correct random number. Only Stack Exchange could have known the right number, so this convinced Let's Encrypt that the request was genuinely from stackexchange.com. Let's Encrypt then signed their CSR, issuing them a certificate. Finally, Stack Exchange installed the certificate and private key on their web servers.

So now we have a CA, Let's Encrypt, that has a root certificate, and we have an end entity, stackexchange.com, that has a certificate signed by Let's Encrypt. Both of these are verifiable by your computer, because your computer has the Let's Encrypt root certificate already present in its "Trusted Root Certificate Store".

When you browse to https://stackexchange.com, your computer looks up the IP address associated with the name "stackexchange.com". But it doesn't know yet if that's really stackexchange or not. The TLS protocol is how both sides of the connection exchange encryption keys and communicate. So you connect to the IP address you were given, and the server at the far end sends you a certificate that says it belongs to stackexchange.com. But is it really them? The next required step of the TLS protocol is for your computer to check the signature on the certificate. Your computer verifies that it was signed by Let's Encrypt. It then looks inside its trusted root store, and if it finds a copy of the Let's Encrypt certificate, it considers the connection valid.

In your example, let's say the MitM hijacked your DNS, and routed your requests to his computer's address. That won't help him, because he doesn't have a legitimate certificate for the DNS name of stackexchange.com. And he can't get one, because Let's Encrypt won't be tricked by his attempts at hijacking their DNS (you can assume that CAs have robust security systems that can detect hijacked DNS server responses.) So when your computer establishes the request to the fake stackexchange.com at the bad address, the bad guys will have no valid certificate to present to your computer. They can send you a self-signed certificate that says the words "stackexchange.com", but your computer won't find the signing certificate in its trusted root certificate store. So TLS will reject the connection, and your browser will warn you of the attempted treachery.

EDIT:

From the comments, it seems that you're assuming that the process between steps 5 and 6 are not protected. But they are protected by TLS certificates.

First, let's look at certificates a bit closer, and that means understanding more of the cryptography used. Creating a digital signature takes a hash value* of a series of bytes (the certificate-to-be-signed, in this case), and uses the private key to compute a signature on the hash. Anyone holding the public key can verify the signature, but they cannot use it to create a signature. It's a one-way operation, the core of security of a digital signature.

* Think of a hash value as a "check sum" of the bytes that is unique to that series of bytes. Computing a hash value of a different set of bytes gives a completely different hash value. Hash values are widely used to detect changes between two sets of bytes; in this case it's being used as a "tamper seal". You can't change a single bit of data on the certificate without making its signature invalid.

A certificate has many data fields on it. One field of course is the public key it contains. Most of the rest of the fields are there to make sure that the certificate shouldn't be trusted for anything else. There's a field that says it's only to be used for validating a server and exchanging session keys. The CN and SAN fields hold the DNS name that it's valid for -- the certificate is not to be trusted unless it came from a connection where that DNS name was used. There's an expiration date, after which the certificate is invalid. And there's an issuer field that says "this certificate was signed by Let's Encrypt, so use the Let's Encrypt certificate to check its signature."

When validating a certificate, you must also find the issuer's certificate, and validate the issuer's certificate as well. If that issuing certificate was also issued by someone else, you keep checking. This is called "walking the chain", and to validate a certificate you must walk the full chain until you reach a self-signed certificate. A trusted CA root certificate has what's called a self-signature. It was used to sign itself, so its issuer field is itself. And that self-signed certificate MUST be in your trusted root certificate store.

The TLS protocol calls for the client to connect to the server and send it a CLIENT HELLO; a message that tells it what TLS version and ciphers it wants to use. The server responds with a SERVER HELLO message that includes its version and list of ciphers, and its certificate containing their public key. The client applies all of the rules above (and more) to ensure the certificate is valid, otherwise it terminates the connection.

Once the certificate is validated, the TLS protocol begins a step called Key Exchange. The server's public key is used by the client to compute a new "session" key, and data is sent back from the client to the server so the server can also compute the same session key. Only the server holding the correct private key associated with the certificate can compute the same session key. If the next message from the server can't be decrypted using the session key, the client terminates the connection.

What all this means is that a client will reject a certificate unless it's met all the rules for having been issued correctly, and will terminate the connection if any part of the exchange fails. It ensures that your steps 5 and 6 are trustworthy.

10
  • 2
    For an example of how CAs try to defend against attacks mentioned here, Let's Encrypt now queries your server from multiple geographically-distributed locations before they will give you a certificate.
    – Danya02
    Oct 15, 2022 at 11:23
  • One thing that should be noted is that a MitM can intercept everything and give you fake certificates for every website, which would mean that you can't use this connection unless you accept their certificate. This can happen if, for example, your government wants to spy on all its citizens. There isn't a way to prevent this, but certificates will at least make sure you know that you are being MitM'd in this way.
    – Danya02
    Oct 15, 2022 at 11:31
  • Thank you very much for this answer, it was very detailed and very helpful. However, I am still thinking, not about the effectiveness and security of the certificate, but only about the assertion that the identity of the server can be reliably confirmed by the verification of the certificate by a CA authority. If the certificate together with the public key public is sent openly and accessible from the server to the client, then it can be freely copied and used by anyone. Between steps 5 and 6, the attacker can claim this certificate as his own.
    – Koala
    Oct 15, 2022 at 12:40
  • The authority will then confirm, yes, the right certificate signed with the right public key. This does not mean, however, that the identity of the server has been verified. What @Yuriko explained to me in the answer above is that the response from the client to the server (let's say after step 5 an 6) is encrypted with the public key contained in the certificate and can only be decoded with the private key, which of course should only be stored by the real server.
    – Koala
    Oct 15, 2022 at 12:42
  • @Danya02: In that case you just accept one fake certificate for a gateway on the other side of the scope of their control, then tunnel all traffic through that gateway, and the fact that they can see and modify the traffic inside the tunnel is irrelevant - the confidentiality and integrity of the data are protected by the next layer of TLS inside. Oct 15, 2022 at 13:35
0

Having the possibility of managed computers using "self-signed" leaf certificates used as CA certificates, or pushing users to accept the installation of a CA certificate used on a MitM attack, then the user does not even verify that his own traffic is being inspected and being actively decrypted.

Browsers should in theory verify this and block the corresponding traffic using a verification towards their DNS servers with client certificate distribution. In this case this would not be a big challenge.

1
  • A nitpick: The good ol' DNS is not such a safe of a communication channel. DoH etc on the other hand... Oct 17 at 16:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .