[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: VPN solution(s) for Fedora Core



James Morris alerted me to the presence of this thread.  I'm the developer of
OpenVPN and I'd be happy to answer any of your questions about it.

One point I'd like to add to the thread is that there are really two classes
of VPNs in active development today, SSL/TLS VPNs and IPSec, and that it
probably makes sense for a distro to include at least one implementation from
each class.

SSL/TLS VPNs implement the bulk of the VPN function in user-space, use SSL/TLS
as the security layer, use an application-level protocol over TCP or UDP as
the transport layer, and use virtual networking interfaces such as TUN/TAP
interfaces as their hook into the network stack.  Some commercial SSL/TLS VPNs
also provide the ability to use a web browser as the client, though this tends
to be more of a marketing twist to sell secure web apps.

IPSec VPNs take a different approach and attempt to tightly couple the
security function with the transport protocols being secured.  For this
reason, IPSec implementations have a much larger kernel footprint and tend to
have a separate implementation for each OS.

Each class really has its own strengths and weaknesses.  SSL/TLS VPNs tend to
be more flexible as far as configuration options are concerned.  For example
OpenVPN supports IPv4 or IPv6 routed VPNs or Ethernet 802.3 bridged VPNs, can
use UDP or TCP as the transport layer protocol, and runs on most OSes in
current use including Linux, Windows (2000 and above), *BSD, Solaris, and OS
X.  OpenVPN is also very flexible in terms of transport protocols, allowing
TCP, UDP, SOCKS, or TCP proxying using the HTTP connect method.  This latter
flexibility allows OpenVPN to work well with both NAT and restrictive firewall
policies.

IPSec wins in the multi-vendor support category, and in the availability of
dedicated hardware.  One would also expect IPSec to have a potential advantage
in the speed department, given that a kernel VPN implemenation doesn't need as
many context switches between kernel and user space for each VPN packet.  In
practice, however, I have not seen this to be a  critical foci for VPN users
simply because network bandwidth and the CPU cost of crypto operations tend to
be the limiting factor in VPN performance.

On the security side, OpenVPN uses SSL/TLS as the authentication and key
exchange protocol, and then uses the ESP protocol derived from IPSec to secure
the IP stream itself (because IP is an "unreliable" protocol, ESP makes more
sense than SSL/TLS to tunnel the actual IP stream over UDP).

While my personal expertise is more in crypto implementation than in crypto
theory, I understand that crypto implementations don't usually succeed unless
implementors and crytography experts can work together at a certain level. 
And I think that by and large this has occurred with OpenVPN, especially in
the way that crypto experts such as Peter Gutmann have had a hand in guiding
the development of the crypto layer.

One point I would make as well when comparing OpenVPN's security to an
in-kernel implemenation such as IPSec, is that as a user-space daemon, OpenVPN
can be run as user/group nobody or in a chroot jail, providing a certain
degree of containment of code injection exploits, should they be discovered.

For a higher level overview of OpenVPN, you might want to take a look at the
slides for the talk I gave at Linux Fest Northwest this year:

http://openvpn.sourceforge.net/papers/BLUG-talk/

James



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]