-1

Here is what I understand about how clients trust the tcp channels they are connected to.

  1. Alice asks Bob for his certificate, signed by a CA's private key
  2. Bob sends the certificate, which includes his common name (domain or ip) and an attached signed version of it.
  3. Alice uses her local public key from the CA to decrypt the signed version and compares it to the certificate to verify Bob's claims.
  4. If it checks out, if it's equal, the tcp layer she is connected to does indeed have Bob at the other end.
  5. Now that the connection has been verified, both can agree on keys to encrypt their communications.

But couldn't an ISP easily intercept and alter all communications to Bob through a proxy setup just for him inside a network switch? Including sending and receiving the certificate to Alice? Bob's communications already go through network switches, that's where his IP actually lives. An ISP could just inject software right in there to do whatever, as if it was Bob, and no one would know.

Furthermore, the whole process can be compromised at every stage, from the moment Bob sends a CSR to a CA.

Seph
  • 158
  • 5
  • What you describe is a man-in-the-middle (MITM) attack by the ISP. This would require the ISP to trick or coerce a trusted CA into issuing a certificate for Bob's site to the ISP. See https://security.stackexchange.com/questions/64352/can-isp-use-mitm-attack-to-break-encrypted-traffic for more info. – mti2935 May 16 '20 at 23:34
  • So here is a wire -----------. It is uninterrupted. Signals race through it. Now I'm going to install a device ------ Device -------. The device takes signals coming in and puts them back out. No one is the wiser. Now I tell the device to take signals coming in, cancel them, and send out its own signal. No amount of certificates is going to stop this device if its careful. Bob sends his cert to Alice. Cert goes through device without tamper. Alice sees its legitimate. Negotiates key exchange. Device reacts, cuts Bob off completely and acts like bob. MITM established. – Seph May 16 '20 at 23:53
  • @Seph The point of the key exchange is that the content is encrypted. Since the "device" let the legitimate certificate through, it won't have the key it needs to decrypt anything. – Joseph Sible-Reinstate Monica May 17 '20 at 00:07
  • Wait I just realized that Bob's public key is included in the cert. As long as you trust the CA, decrypting the cert with the CA public key will give you Bob's public key which you can use thenceforth to encrypt all communications to Bob, including a new key exchange. The ISP can't MITM this unless they compromised a trusted CA. – Seph May 17 '20 at 00:10
  • 1
    Exactly. That's why we rely so heavily on CA's. – mti2935 May 17 '20 at 01:21

2 Answers2

1

There's two pieces to enabling TLS's security model, which yes, does protect an ISP from being able to see the contents of messages between you and a destination server.

The first, as you've mentioned is the certificate signed by a CA. However, the important thing to understand is what the private key assosciated with the certificate is used to sign: A temporary Diffie Hellman (or elliptic curve Diffie Hellman) public key.

Diffie Hellman (or elliptic curve Diffie Hellman) allows two peers to agree on a shared secret using an insecure channel. Wikipedia has a more complete description.

The combination of these things means that your ISP can't manipulate traffic without being able to notice:

  • They do not have a certificate, signed by a trusted CA, or the private key associated bob's certificate.
  • They do not have the diffie hellman private key
ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
Alex Gaynor
  • 181
  • 1
  • 6
  • As far as I understand Diffie Hellman prevents ease dropping, but does not prevent MITM. When Bob sends his "color mixture" to Alice, Eve (ISP) can just intercept that and send her own mixture to Alice, and vice versa the other way around. Now both Alice and Bob have phony mixtures. – Seph May 16 '20 at 22:43
  • 2
    The server's DH parameters are signed by the server's private key. The ISP doesn't have this key, so it can't provide its own parameters in place of the server's and re-create the valid signature. The client (or anybody else) has the server's public key - it's in the certificate and verified by the certificate's signature - so they can (and will) verify the signature on the DH parameters. If the ISP tries to slip their own parameters in to the client, the client rejects them because they don't have the server's signature. – CBHacking May 16 '20 at 23:45
  • How does the client obtain those parameters and why can't an ISP obtain them if my browser can? And how does the DH parameter prevent the MITM? Last question, eventually, a key exchange has to be negotiated over an insecure channel. The ISP merely needs to not tamper with anything up until Alice decides she trusts the connection on the other side and sends this key. Unless she encrypts this key with Bob's public key? Or at least what she thinks is Bob's public key, it could be the ISP's key. I'm guessing the public key is in the cert, but how does the DH parameter come into all this? – Seph May 17 '20 at 00:04
  • Wait I just realized that Bob's public key is included in the cert. As long as you trust the CA, decrypting the cert with the CA public key will give you Bob's public key which you can use thenceforth to encrypt all communications to Bob, including a new key exchange. The ISP can't MITM this unless they compromised a trusted CA. Okay, out of curiosity how does Diffie Hellman play into all this? The above seems secure enough. – Seph May 17 '20 at 00:10
  • @Seph Diffie Hellman gives perfect forward secrecy. Without PFS, a passive eavesdropper (Eve) can record all the ciphertext. Then, later, if Bob's private key is compromised, Eve can go back and use it to decrypt all of the recorded ciphertext. Diffie Hellman solves this problem, by using short-lived ephemeral keys for each session, to achieve perfect forward secrecy. See https://security.stackexchange.com/questions/7690/what-should-i-know-before-configuring-perfect-forward-secrecy – mti2935 May 17 '20 at 13:18
  • I understand how DH works. I even delved into the math. Problem with the answer is that it doesn't outline how the method, proposed alone, prevents MITM. It doesn't. – Seph May 17 '20 at 13:50
0

I'll just answer it since I figured it out by looking at the picture below and since no has given the simple direct answer and I'm getting downvoted for it.

Because Bob's public key is sent with the certificate, the ISP cannot send it's own certificate because no CA will trust it and therefor Alice's CA public key will fail to decrypt an ISP provided certificate. Unless the ISP compromised the CA.

Alice can verify Bob's certificate and extract his public key from it. Using it to encrypt future messages to Bob, including new key exchange.

enter image description here

Seph
  • 158
  • 5
  • FYI, this has happened. In 2011, the CA Diginotor was beached. The Iranian government took advantage of the breach to cause Diginotor to issue fake certificates for gmail.com, then used these certificates with the state-run ISP to spy on its citizens' gmail accounts. See https://threatpost.com/final-report-diginotar-hack-shows-total-compromise-ca-servers-103112/77170/. – mti2935 May 17 '20 at 01:45
  • That is pure conjecture and a theory pushed by intelligence agencies hostile to the Iranian government. The attacker was a 21-year-old Iranian student. He proved his involvement by posting DigiNotar's credentials publicly. He also claimed to have breached GlobalSign and three other certificate authorities. The breach was a gesture of retaliation because he took umbrage with what he claimed was the Dutch government's indirect role in the Bosnian genocide. – Seph May 17 '20 at 02:42
  • I agree that an individual hacker may have been able to breach Diginotar acting alone. But, how would he have had the ability to intercept internet connections originating from over 300,000 unique IP addresses (99% in Iran), from over 40 different ISP's and universities acting alone? See https://blog.trendmicro.com/trendlabs-security-intelligence/diginotar-iranians-the-real-target/ and https://www.crn.com/news/security/231600847/300-000-iranian-ip-addresses-compromised-in-diginotar-ssl-hack.htm – mti2935 May 17 '20 at 13:11