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)
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.