Using Tor to protect against certificate injection by Hotspots
Tor is typically used to attain anonymity and preserve privacy online. This is by far the most common and appealing use for it. Most people without such concerns are not likely to ever install a Tor browser on their workstations, and it’s a pity; Tor has at least one additional use-case which is applicable to a much larger audience. This use-case is the prevention of certificate injection when using untrusted network connections.
The concern of hackers hijacking sessions when one uses an untrusted network, such as Wifi at a coffee shop, is a common one. Users are often discouraged from connecting into their work email, bank accounts, and other sensitive service providers, when connecting through untrusted hotspots. I’ve always found it pathetic at this day and age to still accept any reliance on the network provider. By now, our security should have been entirely independent on the network we use to hook into the Internet, and to a large extent it is. Data is encrypted end-to-end with TLS, making us theoretically never at the mercy of the network provider or neighboring surfers. The main reason we are not there in practice, in spite of TLS, is the possibility of certificate injection.
Certificate injection happens when someone who can control the data going in and out of your device can introduce a fake certificate that impersonates the real one that belongs to the service you are connecting to. In theory again, this should not have been possible thanks to Certification Authorities (CAs) that supposedly assure that only valid servers get valid certificates for their identities. In practice, however, this is not always the case. The CA model has failed numerous times, and suffers from interest misalignment and other well known inherent flaws that make it less reliable than intended.
So what do we do to avoid being tricked into using false certificates? One promising approach was key pinning, which is not very common, unfortunately, to the extent of losing support. The other common approach is to use additional network security solutions around TLS. If something gave the same ubiquitous end-to-end encryption without relying on certificates, we would have used it instead. There is none. But end-to-end is not a requirement when you only want to avoid certificate replacement on the last mile. This is how VPNs (Virtual Private Networks) became a common solution. You encrypt your traffic at the network layer from your laptop at the coffee shop to a trusted VPN service provider, and in addition, the connection from you to the secure service is still encrypted end-to-end with TLS as it usually did. You essentially introduce a second layer of encryption that protects only the last mile, from you to the VPN service provider; encryption which is not reliant on replaceable certificates. The VPN service provider can inject fake certificates at its termination point, of course, but this is one service provider that you pay and trust, unlike all the different coffee shop and all the other surfers that lurk there.
The drawback? Cost and complexity. You need to set up encryption at the network layer and pay VPN bills. If you do not otherwise need a VPN, you are not likely to ever do this.
On the other hand, TOR is free, it is integrated at the browser level thought TOR Browser, and takes five minutes to install and five seconds to launch. If you connect to your service through Tor, you gain anonymity, but as a byproduct, you add a layer of encryption that protects you against certificate injection on that last mile of the coffee shop that you connect through. As with the VPN, where you need to trust the VPN service provider to not inject fake certificates, with Tor you will need to trust the Tor exit node to not do that. You can restrict the use of exit nodes to those you trust, as you would choose VPN service providers.
For the occasionally and realistically paranoid, this is a worthy approach.
Display comments as Linear | Threaded