Coda to "Linux's answer to MS-PPTP"

[Peter Gutmann]

My recent posting about problems in some open-source VPN products generated
quite a bit of mail, particularly after it turned up on slashdot (for the
first time in years I got more real mail than spam).  This is a followup to
address some points arising from the original.  In case people are
archiving/re-posting the original article, please attached this as a coda to
that.  I'll also be putting up a long-term copy at
http://www.cs.auckland.ac.nz/~pgut001/pubs/linux_vpn.txt (linked off my home
page) in the next few days.

The main purpose of the writeup was to point out that it's just as easy to
create insecure "security" software with open source as with closed source,
thus the title of the article.  Microsoft took a fair bit of flak over their
insecure PPTP implementation, but there are open-source alternatives that are
just as bad.  The article wasn't meant to be an exhaustive survey of Linux (or
any OS in general) VPN software, since there's way too much of this around to
cover it all.  As with X window managers a few years ago, there are probably
enough VPN packages around for every user to have their own personal one
without much overlap.  Just as with WMs, there will probably be a general
shakeout leading to a smaller number of widely-used ones, driven by a
particular environment (kwm driven by KDE, Sawfish driven by Gnome) and a
large number of lesser-used alternatives driven by user preference.  The
problematic ones will still continue to be used for some time, for example Ed
Gerck pointed out a Linux Journal article published only last month (Linux
Journal, August 2003, p.84, http://www.linuxjournal.com/article.php?sid=6675)
that recommends the use of vtun, the least secure of the three that I looked
at, but hopefully the better ones will come to predominate.

As with window managers, the same move towards a small number of standardised
VPN apps will probably occur over time in the open-source community.  Although
I deliberately omitted mentioning them in the original writeup because
specifically pointing to one particular implementation would be seen to
implicitly exclude anything else and because predicting the future is always a
dicey proposition, I'm guessing that the two major players will probably be
Free S/WAN (http://www.freeswan.org/) and OpenVPN 
(http://openvpn.sourceforge.net/) or something very much like it, with Free
S/WAN representing the IPsec approach and OpenVPN representing the SSL-based
approach that I described in the article (to paraphrase Winston Churchill,
"SSL is the worst way to build a VPN, except for all the others").

Free S/WAN, being an IPsec implementation, inherits all of the IPsec
complexity that seems to have been the inspiration for the creation of several
of the non-IPsec VPN applications.  There are also quite a number of
complaints from users that Free S/WAN is excessively difficult to use if you
want anything more sophisticated than a straightforward setup using pre-shared
static keys, more so than most normal IPsec implementations (please, no
flamewars over this, I'm just reporting user comments and experience).  There
also exists an IKE-less IPsec implementation called ipsec_tunnel 
(http://ringstrom.mine.nu/ipsec_tunnel/) that uses the Linux (not Microsoft)
CryptoAPI and that was also inspired by the difficulty in using Free S/WAN
("it was hard to understand and hard to configure").

OpenVPN is the "IPsec is too complex" alternative, running a TLS-protected
dual control/data channel session over either TCP or UDP, with a reliability
layer added for the control chanel if it's running over UDP.  The manpage
indicates that the data channel doesn't have this since tunnelling TCP will
provide the necessary facility, but that makes tunnelled protocols without
built-in reliability facilities vulnerable to message insertion or deletion.
This could cause problems in cases where users assume that the use of a secure
tunnel gives them this additional protection.  A note in the manpage to
indicate that OpenVPN provides only the same facilities as the protocol being
tunnelled would be useful in clearing up any possible confusion.  Overall, the
choice of how to handle this is a tradeoff: You can either have protection
against message insertion (strictly speaking, message replay), deletion, and
reordering, but the first occurence of UDP unreliability will be detected as
an attack by the security layer and the connection terminated, or you can have
the ability to live with UDP's unreliability, at the cost of not detecting
insertion/deletion/reordering at the VPN level.

In terms of security, Free S/WAN is an implementation of the IPsec design and
so should be as secure as any other IPsec implementation.  OpenVPN uses
OpenSSL's SSL/TLS for its control channel, and so should be as secure as
SSL/TLS in general.  For the data channel it uses encrypt-then-MAC with
explicit IVs (these will be added to TLS 1.1), which is good.  The key
management step (that is, how to get from the SSL control channel to the data
channel) is documented only in the source code, which I don't feel like
reverse-engineering, but a quick look through it indicates that the author
knows what he's doing.  One thing that would be nice here is an RFC
documenting a standard way to do this, to allow compatible implementations to
be created by others doing SSL-based VPN work.  Something based on experience
with OpenVPN and other tunnelling implementations that may be around would be
useful here (I'm currently bugging various people about this).

My focusing on those two imlementations should not be taken to mean that
everything else not mentioned above is insecure.  I'm was aware of a number of
other VPN implementations, but had no idea just how many there really were
until people pointed a great many of them out to me in email, and I really
don't have time to go through them all.

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com