Private WANs may be less secure than VPNs

The latest round of Snowden revelations concern a British GCHQ program dubbed "Mastering the Internet (MTI)". The program involves, among other things, tapping the world's under-sea fibre-optic cables and systematically monitoring all communications.

One of the most significant facts that appears is the benefit of using IPsec and VPNs over the public Internet instead of trusting un-encrypted traffic to pass over private WAN connections. The definition of a private WAN connection is quite broad: many ISPs in the UK, for example, use the British Telecom OpenReach platform to tunnel DSL connections back to their data centers and offer virtual WANs to their business customers.

Can any wifi be trusted?

It should be assumed that all Wifi networks can be compromised at-will by a sophisticated attacker. This is another situation where VPNs may be part of the solution: even WPA2 secured wifi segments should be treated as untrusted public Internet networks and not bridged or routed onto any private subnets. Users with devices on a wifi network should be forced to use a VPN over wifi connection, even when the wifi is within the same building as the private network.

Tor may be compromised by an attacker with this much data

As I've mentioned in previous blogs with a focus on real-time communications there is no such thing as perfect privacy.

Simply encrypting data with IPsec does not prevent the attacker knowing the volume of data transmitted or the time it was transmitted. Using a service like Tor for onion-routing provides some benefit. However, an attacker with sufficient infiltration of many points in the network may be able to deduce the real origins of a data transfer over Tor using some combination of packet sizes and timestamps. "Mastering the Internet (MTI)" may have sufficient coverage to achieve that. Tor could overcome this by putting dummy data into the network and adding fragmentation, but such schemes may add latency, reduce throughput and require significant effort to upgrade existing users.

Gaining intelligence from encrypted data

VoIP signals are typically compressed using some type of codec. These are dedicated, lossy compression schemes optimised for voice signals. Some codecs use a fixed compression ratio. Other codecs use a variable compression ratio (VBR): a simple example involves sending shorter packets to indicate a period of silence. Encrypting these packets prevents an attacker seeing what is inside them but the attacker can easily detect the lengths of the packets. Researchers have demonstrated that statistical techniques can be applied to VBR dataflows to identify syllables used in speech and then make a hypothesis about what has been said. (This would be an interesting hack to try and reproduce by collecting data with tcpdump and analysing it with R)

Identifying phrases in encrypted VoIP using statistical analysis

In many cases like those described, it is necessary to go beyond default encryption settings and put extra dummy data or frame padding into the data flow to gain a more fool-proof level of privacy. Simply connecting VoIP phones to an IPsec network doesn't automatically make them secure.

The rise of the free-software VPN

Even if the default configurations are not always universally resilient to every type of attack, many free software prodcuts provide an excellent building block for VPNs. Having the source code and specifications on hand, free software developers can then innovate to mix-and-match different technologies or add random data flows to mask the real activity on the network.

In a recent hosting migration project, I successfully used the rather trivial VPN package tinc to bridge the ethernet segments between virtual machines in the old and new networks. This allowed virtual machines to be moved one-by-one over a period of a week. This is a remarkably simple solution that can protect the integrity of communications on a private subnet.

A more comprehensive solution is strongSwan which provides support for industry-standard IPsec in various topologies. They now offer a full IPsec client for Android phones (hopefully it will be made available on f-droid: using a Google account to access Google Play may result in Google accidentally helping you "back up" your settings, including credentials, to their cloud, undermining the privacy of the system)

An IPsec VPN can be deployed to all hosts on a network: then they can use opportunistic encryption for any type of communication without needing to worry about the underlying network. Furthermore, it is possible to add smart cards to further boost VPN security while using free software for the whole solution.

For those interested in looking beyond Linux solutions, the *BSD range of operating systems, particularly OpenBSD provide a compelling alternative. This paper about OpenBSD's iked, which is also available on other platforms as OpenIKEd is very recent and provides a thorough overview of it's current status. One notable limitation is that their MOBIKE support is not yet complete.

Many older VPNs likely to need an ugprade

When I first started deploying Linux VPNs in the 90s the market was favourable for any type of Linux VPN. In extreme cases (which were surprisingly common at the time) companies accustomed to paying $20,000 per month for a leased line would happily pay a flat fee of $100,000 to purchase a VPN that was cobbled together using less than $10,000 of commodity hardware and some free software. Many of the first generation of these VPNs were built using RSA key lengths and algorithms no longer considered secure, such as DES. Some of these solutions (or products derived from them) may still remain in use today: managers may be slightly embarrassed to put aside their $100,000 VPN and replace it with a $50 router that is more secure. While that is the more extreme example, there are many intermediate solutions out there in the field. There are clear opportunities here to upgrade users to free software solutions.


To protect against casual, passive eavesdropping I think we should aim for a minimum floor of encrypted transport by default, even if we can't yet authenticate the endpoints.

Examples would be allowing (opportunistic) TLS on a mailserver, or allowing HTTPS connections with merely a self-signed certificate.

I think IPSEC is a good way to go, especially in combination with IPv6 deployment making end-to-end connectivity a lot cleaner. It's nice to be able to protect everything at once, between whole sites/prefixes, with one mechanism.

Between two offices for example, that might cover internal DNS zones, any plaintext HTTP/FTP/SMTP traffic, unsecured XMPP or VoIP sessions and other (non-cloud) proprietary software that connects between sites. It's not surprising if people consider it too much effort to secure these services individually.

I wonder if's viable, for some services, to attempt IPSEC keying on all their outgoing connections to the public Internet, falling back to plaintext as a last resort. As more people/organisations support this on servers/routers it would reduce the effectiveness of dragnet surveillance, being vulnerable only to deliberate interventions (such as blocking the key exchange, or MITM attack).

I think, particularly given recent revelations related to government snooping, it's insane that VPNs haven't become a standard tool for even casual internet surfers. As far as I'm concerned, a turning a VPN on, especially when you're on public WiFi, should be as natural as locking the door when you leave home. It's not even expensive! There are a ton of excellent paid services out there (Private Internet Access, Hide My Ass)and even some fabulous free ones (SumRando VPN).

Some of those services you mention are not a privacy-enabling service. They simply provide a convenient form of misdirection. For example, there are millions of British people who retired to the south of France or Spain but were blocked from accessing the Olympics on the BBC web site. VPNs back to the UK helped them get British IP addresses. The type of VPN I've described is for controlled private networks: where people want to more tightly control access from smart phones and laptops to their mail servers, etc. Currently, many people expose IMAP servers and other types of service assuming it is protected by SSL. That is not entirely true however and a privately run VPN is often a better solution.