Paranoid Penguin - Linux VPNs with OpenVPN

Nowadays, a number of good VPN solutions exist for Linux. Some
commercial products, of course, release Linux versions of their proprietary
VPN client software (so many more than when I began this column in 2000!).

In the IPsec space, there are Openswan, which spun off of the FreeS/WAN
project shortly before the latter ended; Strongswan, another FreeS/WAN
spin-off; and NETKEY (descended from BSD's KAME), which is an official part
of the Linux 2.6 kernel and is controlled by userspace tools provided by
the ipsec-tools package. All of these represent IPsec implementations for
the Linux kernel. Because IPsec is an extension of the IPv4 protocol,
any IPsec implementation on any operating system must be integrated
into its kernel.

vpnc is an open-source Linux client for connecting to Cisco VPN servers (in
the form of Cisco routers, Cisco ASA firewalls and so forth). It also
works with Juniper/Netscreen VPN servers.

Although I don't recommend either due to PPTP's security design flaws,
PPTP-linux and Poptop provide client and server applications, respectively,
for Microsoft's PPTP protocol. Think it's just me? Both PPTP-linux's and
Poptop's maintainers recommend that you not use PPTP unless you have no
choice! (See Resources for links to the PPTP-linux and Poptop home pages.)

And, of course, there's OpenVPN, which provides both client and server
support for SSL/TLS-based VPN tunnels, for both site-to-site and remote-access use.

Introduction to OpenVPN

All the non-PPTP Linux VPN tools I just mentioned are secure and stable.
I focus on OpenVPN for the rest of this series, however, for two
reasons. First, I've never covered OpenVPN here in any depth, but its
growing popularity and reputation for security and stability are such that
the time is ripe for me to cover it now.

Second, OpenVPN is much simpler than IPsec. IPsec, especially IPsec on
Linux in either the client or server context, can be very complicated and
confusing. In contrast, OpenVPN is easier to understand, get working
and maintain.

Among the reasons OpenVPN is simpler is that it doesn't operate at the
kernel level, other than using the kernel's tun and tap devices (which
are compiled in the default kernels of most mainstream Linux
distributions). OpenVPN itself, whether run as a VPN server or client, is
strictly a userspace program.

In fact, OpenVPN is composed of exactly one userspace program,
openvpn, that can be used either as a server dæmon for VPN clients to
connect to or as a client process that connects to some other OpenVPN
server. Like stunnel, another tool that uses SSL/TLS to encapsulate
application traffic, the openssl dæmon uses OpenSSL, which nowadays is
installed by default on most Linux systems, for its cryptographic
functions.

OpenVPN, by the way, is not strictly a Linux tool. Versions also
are available for Windows, Solaris, FreeBSD, NetBSD, OpenBSD and Mac OS X.

2009: a Bad Year for SSL/TLS?

OpenVPN depends on OpenSSL, a free implementation of the SSL and TLS
protocols, for its cryptographic functions. But SSL/TLS has had a bad year
with respect to security vulnerabilities. First, back in February 2009,
Moxie Marlinspike and others began demonstrating man-in-the-middle attacks
that could be used to intercept SSL/TLS-encrypted Web sessions by
“stripping” SSL/TLS encryption from HTTPS sessions.

These are largely localized attacks—in practice, the attacker usually
needs to be on the same LAN as (or not very far upstream of) the
victim—and they depend on end users not noticing that their HTTPS
sessions have
reverted to HTTP. The NULL-prefix man-in-the-middle attack that Marlinspike
and Dan Kaminsky subsequently (separately) demonstrated that summer was
more worrisome. It exploited problems in X.509 and in Firefox that made it
possible for an attacker essentially to proxy an HTTPS session, breaking
the encryption in the middle, in a way that allows the attacker to
eavesdrop on (and meddle with) HTTPS traffic in a way that is much harder
for end users to notice or detect.

But, that wasn't all for 2009 (which isn't even finished yet, as I write
this). In November, security researchers uncovered problems with how the
SSL/TLS protocol handles session state. These problems at least
theoretically allow an attacker not only to eavesdrop on but also inject data
into SSL/TLS-encrypted data streams. Although the effects of this attack
appeared similar to those of the NULL-prefix attack, the latter involved
client/browser-side X.509 certificate-handling functions that were
browser/platform-specific and didn't involve any server-side code.

In contrast, the November revelation involved actual flaws in the SSL/TLS
protocol itself, whether implemented in Web browsers, Web servers or
anything else using SSL/TLS. Accordingly, application or
platform-specific patches couldn't help. The SSL/TLS specifications
themselves, and all implementations of it (mainly in the form of
libraries such as OpenSSL), had to be changed.

That's the bad news. OpenVPN depends on protocols that have been under
intense fire lately. The good news is, because e-commerce, on-line
banking and scores of other critical Internet applications do as well, at
the time of this
writing, the IETF has responded very rapidly to make the necessary revisions
to the SSL/TLS protocol specifications, and major vendors and other SSL/TLS
implementers appear to be poised to update their SSL/TLS libraries
accordingly. Hopefully, by the time you read this, that particular issue
will have been resolved.

Obviously, by even publishing this article, I'm betting on the continued
viability of SSL/TLS and, therefore, of OpenVPN. But, I'd be out of character
if I didn't speak frankly of these problems! You can find links to more
information on these SSL/TLS issues in the Resources section.