<< | Thread Index | >> ]    [ << | Date Index | >> ]

To: David Brodbeck <DavidB,AT,mail,DOT,interclean,DOT,com>
Subject: RE: Long message - thoughts on Gutmann response
From: "Dick St.Peters" <stpeters,AT,NetHeaven,DOT,com>
Date: Wed, 24 Sep 2003 17:19:09 -0400
Cc: cipe-l,AT,inka,DOT,de
In-reply-to: <C823AC1DB499D511BB7C00B0D0F0574C58413D@serverdell2200.interclean.com>
References: <C823AC1DB499D511BB7C00B0D0F0574C58413D@serverdell2200.interclean.com>

David Brodbeck writes:
> - I have yet to see an SSH/SSL-derived VPN system that's suitable for
> production use.  The only ones I know of are PPP-over-SSH or PPP-over-SSL.
> These will always be horribly broken because they tunnel TCP over TCP, which
> is Considered Harmful due to retry timer issues.  They work until you start
> getting dropped packets, but then they succumb to spiralling death syndrome.

OpenVPN rides UDP, can use SSL encryption, is available for a lot of
platforms (including most newer Windows), and got a good preliminary
review from Gutmann - see forwarded posting below.

In addition, OpenVPN includes compression using the LZO compression
library on systems supported by LZO.  OpenVPN also supports bridging.
In road-warrior situations it's highly tolerant of IP changes.

For cases where high-security isn't needed, OpenVPN supports use of
static keys.

The one thing it doesn't offer is a pkcipe equivalent.

Dick St.Peters, stpeters,AT,NetHeaven,DOT,com 

From: Thomas Glanzmann <sithglan,AT,stud,DOT,uni-erlangen,DOT,de>
Sender: openvpn-users-admin,AT,lists,DOT,sourceforge,DOT,net
To: openvpn users <openvpn-users,AT,lists,DOT,sourceforge,DOT,net>
Subject: [Openvpn-users] pgut001,AT,cs,DOT,auckland,DOT,ac,DOT,nz: Re: tunnel 
solutions: openvpn]
Date: Wed, 24 Sep 2003 09:17:06 +0200

----- Forwarded message from Peter Gutmann 
<pgut001,AT,cs,DOT,auckland,DOT,ac,DOT,nz> -----

Date: Wed, 24 Sep 2003 13:34:42 +1200
From: Peter Gutmann <pgut001,AT,cs,DOT,auckland,DOT,ac,DOT,nz>
To: Thomas Glanzmann <sithglan,AT,stud,DOT,uni-erlangen,DOT,de>
Subject: Re: tunnel solutions: openvpn

>I just read your article about VPN solutions. Did you had a look at
>openvpn[1]?! Any comments.

Apologies for the form-letter reply below, I got a ton of mail over this after
it was mentioned on slashdot, so I've written a general summary for questions
of the "What about Free S/WAN, OpenVPN, <other VPN software>" type.


-- Snip --

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.

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 others driven by user preference (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

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

Free S/WAN, being an IPsec implementation, inherits all of the IPsec
complexity that seems to have been the inspiration for the creation of a
number 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).

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 the additional facility of message insertion/deletion
protection.  A note in the manpage to indicate that OpenVPN provides the same
facilities as the protocol being tunnelled would be useful in clearing up any
possible confusion.

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.

Focusing on those two imlementations should not be taken to mean that
everything else not mentioned above is insecure.  I'm aware of a number of
other VPN implementations (and there are even more that were pointed out to me
in email), but really don't have time to go through them all.

In case anyone wants a long-term link to this, I'll be putting a copy up at
http://www.cs.auckland.ac.nz/~pgut001/pubs/linux_vpn.txt in the next few days.

----- End forwarded message -----

This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
Openvpn-users mailing list

<< | Thread Index | >> ]    [ << | Date Index | >> ]