Stuff Yaron Finds Interesting

Technology, Politics, Food, Finance, etc.

Why TLS doesn't replace VPN for Enterprise customers

If you can establish a TLS connection to your enterprise remotely. then why do you need VPN/IPSEC? Given that any TCP based protocol can be run over TLS it would seem that the ubiquitous support for TLS has solved our remote access end-to-end security problems.

There are many interesting protocols in the world, especially notification and streaming ones that do not run over TCP, they generally use UDP. TLS's connection oriented nature does not support UDP but IPSEC, because it operates at the IP layer, does support UDP. A TLS only world is a TCP only world.

In order for a TCP service behind the firewall to be available over TLS the firewall has to be configured with an externally visible IP address, usually a DNS name and a specific port that then hooks into the desired service. This means that if some user wants to make their HTTP server on their desktop PC available remotely over a secure, encrypted connection they first have to stop off at IT and get an IP address/DNS name/Port combination that is configured back to their machine. It is not in IT or anyone else's interest to put such access roadblocks in front of people who are securely accessing their own networks.

Mirroring all the DNS names, IP address and ports externally over TLS could solve the visibility problem. Although doing this exposes the internal DNS tree and requires a huge increase in the number of globally accessible IP addresses. The danger of exposing the internal DNS tree is debatable although internal names can provide some interesting intelligence and starting points for attacks. Another alternative is to provide a TLS connection to the DNS server and then only mirror IP address and ports on request. The DNS tree will only be exposed over an encrypted connection and only as many IP addresses and ports as needed will be created. This causes trouble if the remote device is ever brought into the internal network since it's DNS cache will be filled with nonsense. One has to be careful any time end-to-end connectivity is broken. There are still performance issues since, if memory serves, each TCP connection has to negotiate a new TLS session where as an IPSEC session is used across all TCP and UDP communications.

If TLS is hit hard enough with a big enough hammer it can be made to serve as a VPN for TCP. But given the need for UDP and given that VPNs in general and IPSEC in particular exist and have been demonstrated to securely and reliably handle all end-to-end security issues without requiring changes to the internal network infrastructure, without adding additional IP address and without unnecessary performance hits, why not just use a VPN?

Leave a Reply

Your email address will not be published. Required fields are marked *