1

I've looked for similar questions but can't quite find the answer I need.

Preventing a spoofing man in the middle attack?

After reading this question:

"Authorized" Man in the middle

I think I can grasp the problem (simplified).

Client attempts to make a connection to a target server. A proxy hijacks the connection. The proxy initiates an encrypted connection to the target server. The proxy creates a forged certificate and sends it to the client and starts an encrypted connection. The proxy is then a man in the middle.

Without a CA the client does not know if they have made a genuine connection.

My question is about how the proxy manages to hijack the connection. If the clients DNS was compromised I could see a case where the IP resolved could be the proxies IP.

If the client makes a connection directly using an IP address, would the the proxy still be able to intercept the traffic? Perhaps a hostile router could do this.

Community
  • 1
Uzer
  • 113
  • 5
  • *"..re-encrypts the message with its own public key .."* - In TLS the traffic is not encrypted with the public key of the certificate but with a symmetric key determined during key exchange. The public key in the certificate is primarily used to check that the server own the certificate and in some kinds of key exchange. – Steffen Ullrich Feb 10 '17 at 18:39
  • Ah! Right you are. The message in this case is their shared secret. – Uzer Feb 14 '17 at 00:21

3 Answers3

2

If the proxy is in the path of the connection it can intercept the traffic. This is the case of a proxy explicitly defined in the browser and also with transparent proxies installed on a device where all outgoing traffic must pass thru (like a firewall). It is also the case when an attacker in the local network redirects traffic using ARP spoofing. DNS spoofing is only relevant if hostnames are involved but all the other cases work with IP address as target too.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
1

Basically all communication can be intercepted if it is taken off the wire, no matter where it goes. TCP/IP needs to be routable, hence packages can be inspected (read-only) but also tampered (re-written) by any node between sender and receiver.

Layer-3 routers and firewalls with packet inspection can do this easily, even on a large scale due to computing power got cheap (10000 of packets per second is no problem). Guess what NSA is doing, they exactly use these hardware parts.

In my company for example, we use a so-called WAN-accelerator that tries to cache http(s) traffic in order to not have so much load on our intra-company WAN links. The idea is a good one, but here comes the problem: many sites use already https, so the WAN accelerator could not accelerate anything.

To be able to do it, all our computers get a trusted certificate pushed by the group policy in Windows or stored in AD, I don´t know the background. Then, the WAN accelerator finds a packet which has a https (SSL) exchange inside, and replaces as you described the public key (It will also deliver a "forged" certificate with the DNS name that the client requested or probably an IP address if no name is given) so that the client is fooled into thinking he is communicating securely with the final receiver.

Instead it´s communicating with the WAN accelerator, and it can now cache / accelerate whatever.

Point is, my company (or my IT guys in my company) can (theoretically) read all my private banking traffic etc. at this accelerator node. How cool is that!

You will still see that these sites don´t have the "green badge" in the browser bar maybe, but there will be no warning about the interception.

flohack
  • 547
  • 3
  • 8
1

Yes the proxy always intercepts the traffic.

No it can't read the traffic if using the intended target's certificate.

Yes it can read the traffic if it spoofs the public key, but the browser will display a warning, so

No there is no way to intercept and read the traffic without generating a browser warning.

My explanation starts with this sentence:

The proxy creates a public key and sends it to the client and starts an encrypted connection.

That is not quite how it works. The proxy would have to send a fake certificate to the browser, which would include the public key but would also have to contain other information, such as the domain that owns the key. In addition, the whole certificate is digitally signed and therefore tamper-resistant. The signature can be verified by using the public key of the organization that issued the certificate. That public key is in turn verified by another SSL certificate, all the way up the chain, until you reach the CA. The CA certificate is installed as part of your operating system, so its public key is well-known.

So, unless the proxy has one of the private keys from the chain of trust, it is impossible for the proxy to provide the browser with a fake certificate or alternative public key without the browser knowing that it is fake-- it can't generate the signature.

If the proxy cannot provide a fake, there is no way to convince the browser that the public key and the domain name go together, and your browser will display a phishing warning, turning the address bar red.

Even if you are accessing a host via IP address, the certificate is still required, and the domain name on the certificate can still be seen by the end user. The browser will always turn the address bar red. Also, the end user can click a button on the browser to view the certificate and manually determine if the domain name is correct. If the domain name is suspicious, the user is supposed to close the browser and stop using that endpoint.

John Wu
  • 9,101
  • 1
  • 28
  • 39