How do I check that I have a direct SSL connection to a website?

Question

I always thought that if I had an SSL connection there would be no MITM attacks. Now it appears that isn't true (see comments in this question Is it okay from a security perspective to read foreign (untrusted) cookies in a trusted network?)

I'm still unsure how it works and whether each browser needs to install a certificate, but it sounds like a proxy on your LAN connection either redirects the domain (I probably misunderstood) or uses an alternative certificate (doesn't the cert need to match the domain? I'm still confused).

Would it be possible to check if I am connected to the true site? It would be helpful too if you can explain how the proxy can create a valid cert for a domain it doesn't have the real cert/keys for. (I know this is two questions but both can potentially be explained by one answer.)

Answer 1

To verify that you're talking to the remote server you want directly, two points are required:

• You need to check you trust the server certificate (typically done via RFC 3280/RFC 5280).
• You need to check that the certificate was issued for the host name you're trying to reach (RFC 2818 Section 3.1 and RFC 6125).

What constitutes that remote server is up to the service provider. You're confusing multiple kinds of proxy servers here.

• There are normal HTTP proxy servers that can be used for HTTPS connections. This is done using the HTTP CONNECT verb and the entire SSL/TLS traffic between the browser and the target server is merely relayed by the proxy server. As far as the SSL/TLS connection is concerned, this is roughly equivalent to IP routing: the proxy won't see anything.

• There are HTTP reverse proxy servers. This is what's discussed in the question you link to. However the request is then handled internally is up to the service provider.

  In the same way as for database connections, it may be useful for the service provider to protect its internal HTTP traffic using SSL/TLS, if the requests are served by HTTP worker nodes. In this case, the head node of the load-balancer/reverse proxy will be the client to those internal web servers.

  As far as you're concerned, the "true site" is the head node/reverse proxy. https://www.google.com/ certainly has more than just one box to handle the requests it gets. As far as you're concerned, the entire cluster behind it is the (big) machine.

• MITM proxy servers. Some HTTP proxy servers will be able to look into the HTTP traffic (for example Squid + SSL Bump). To do so, they will re-generate a certificate using their own Certification Authority on the fly. Such certificates will fail validation in your browser (step 1 above), unless your machine has explicitly been configured to trust this local CA.

Answer 2

If you're using an SSL proxy, you must be specifically configured to trust the proxy. The proxy uses a wildcard certificate, so your browser will accept its certificate for any site. Obviously, using an SSL proxy you don't completely trust is a very bad idea.

Normal HTTP proxies can proxy SSL, but they just copy the data, they cannot change or decode it. You still see the site's normal certificate.

If you're concerned about poor security on the website's side, there's nothing you can check or do about that. They're entitled to decrypt all the data you choose to send to them. If they don't protect it, there's nothing you can do about that. If they're using a proxy internally to be the SSL endpoint, it's their responsibility to keep the decrypted data secure on their internal network. There's nothing you can do if they compromise the data. They are supposed to be able to handle the decrypted data however they want.

SSL only protects the data between the two SSL endpoints.

Answer 3

The only way a proxy can act as a man-in-the-middle (assuming that the client and the server correctly implement a non-broken version of the SSL/TLS protocol, and that the certificate authorities do their job correctly) is if your browser trusts the proxy. That's because at the start of the connection, the client validates that the other endpoint has a valid certificate generated by a recognized certificate authority.

There may be a proxy between the client and the server. This is common on enterprise networks, for example, which often have no direct connection between inside hosts and the Internet. But the proxy can only exchange bytes back and forth. It cannot know, let alone modify, the content. It can know which IP address you're connecting to, but not which URL you're browsing.

So what can go wrong? If your browser recognizes a CA that is willing to sign that proxy.example.com is the server that the client is trying to connect to, then proxy.example.com can make its own connection to the server, and the client's connection may be visibly or transparently redirected to the proxy. Then the proxy is a man-in-the-middle.

Some enterprise networks configure all clients to trust the enterprise's own certificate authority, and impose a proxy that rewrites all SSL connections. The client then sees every site having a certificate signed by the enterprise's CA. Since all certificates have a valid signature, you won't notice this in everyday usage. The way to find out if this is happening (assuming the browser itself hasn't been tampered with, only its certificate list) is to check who signed a particular certificate, or to browse the list of trusted certificate authorities.