>* Stefan Mink:
>
>> a) It would be good to hear from this community if there
>> are any negative aspects of OpenVPN (vs. IPsec VPNs).

>It's not standardized, and it only interoperates with itself (but this
>is true for many IPsec implementations as well).  This is more than
>compensated by its portability.  OpenVPN has a very interesting
>feature set, including hybrid authentication and a HMAC-based
>integrity check before TLS processing for the paranoid.  (Static key
>mode is also possible and doesn't require TLS at all.)

While it's true that OpenVPN's protocol is not yet standardized,
I would argue that an important niche in network security, namely
the forwarding of entire virtual network interfaces (and not merely
ports), and doing this all from userspace, was not being
addressed by existing protocols.

SSL/TLS does a good job of tunneling reliable transport protocols
such as TCP from userspace.  IPSec does a good job of tunneling
protocols which use unreliable semantics, such as IP, from kernel
space.  ssh is great for forwarding TCP ports.  But no protocol
existed at the time of OpenVPN's inception to tunnel unreliable
protocols from user space (because VPNs tunnel protocols which
are designed to operate at the physical layer, it is important
for VPNs to use a security layer which operates at the datagram
semantics level -- this means you want something like a TLS protocol
which can tunnel UDP).

This void has been recognized by others, and led to the development
of Datagram TLS (DTLS) by Negendra Modadugu and Eric Rescorla.

http://crypto.stanford.edu/~nagendra/papers/dtls.pdf

This approach of developing a variant of TLS for securing a UDP
stream is similar to that taken by OpenVPN.  DTLS can be
implemented inside the OpenSSL library as a variation to TLS.
OpenVPN takes a different approach and uses standard TLS,
but encapsulates it inside a reliability layer, not unlike the
way that TLS over TCP accomplishes the same objective.

I expect that future versions of OpenVPN will gravitate towards
using DTLS as the security layer, as this is in line with OpenVPN's
modular approach to security where as much as possible, encryption
and authentication functions are offloaded to an independently
developed crypto library such as OpenSSL.

Another reason why OpenVPN was forced to implement its own
TLS-based VPN protocol is that it uses a user-space daemon execution
model.

Why tunnel from user-space?  For the same reason that ssh or
apache + modssl runs in userspace:  portability and security.

Portability: Why write a complex piece of code only to have to
reimplement it for every OS in existence?  A major reason why OSes
exist in the first place is to provide a platform for the development
of portable code.  Unless code requires the special execution
environment of kernel mode, i.e. access to privileged CPU
instructions, direct hardware I/O, extreme performance requirements,
or the ability to disable preemption, why not implement in user-space
and get all of the advantages of portability and stability?

Security: Implementing network security code in the kernel disobeys
a cardinal rule of security: never design a security model so that
a single failure causes a catastrophic security breach.  Kernel mode
code is never further than one buffer overflow away from root
compromise.  Implementing security in userspace provides the
additional security buffer that exists between user and kernel space:
a daemon can setuid/gid to nobody and chroot to an empty jail.
Now a buffer overflow in the userspace daemon doesn't mean an
automatic root compromise.  It makes a root exploit much more
challenging to develop because you first must compromise the daemon,
then install a secondary exploit which takes advantage of a local
root exploit in the OS.  Essentially you need to simultaneously exploit
two vulnerabilities in unrelated code in order to gain root access.

Flexibility:  I think about OpenVPN as being a kind of ssh which
allows a more flexible port forwarding model:  a very useful feature
of ssh is that it can do secure TCP port forwarding.  But that's just
a special case of the more general problem of securely forwarding
an entire virtual network interface.  OpenVPN tries to solve this
problem by letting you create a virtual ethernet or point-to-point
IP interface on system A and securely connect it with a similar
interface on system B.

You could think of ssh as being a TCP port forwarder while OpenVPN
can forward an entire virtual network interface.  Forwarding a virtual
interface means that all TCP and UDP ports are forwarded, all IP
protocols are forwarded, etc.  The routing table and firewall config
are used to decide which applications get routed over the VPN or
blocked.

>Unfortunately, the protocol would have to be reverse-engineered from
>the source code before it can be reviewed.  You've already mentioned
>important aspects of the protocl (TSL on the control plane, ESP for
>the payload).

Writing a comprehensive RFC-style description of the OpenVPN protocol
is definitely in the plan, though I've been busy working on OpenVPN
2.0 and haven't yet been able to find the time.

Currently the best way to understand the OpenVPN protocol is to read
the security and protocol overview:

  http://openvpn.net/security.html

I've recently updated this page with additional detail on the OpenVPN
protocol itself.

Also, see this well-written article by Charlie Hosner that provides
a higher-level security overview:

http://www.sans.org/rr/papers/20/1459.pdf

>What's still missing, though, is multicast support and PPPoE-style
>multihop authentication.

Multihop authentication is not supported, however multicast can be
routed through OpenVPN.  While OpenVPN doesn't explicitly handle
multicast, you can set up mrouted on OpenVPN's virtual tun or tap
interfaces.

>PMUTD doesn't work for me at the moment, but
>this could also be a local configuration problem.

PMUTD should work fine through OpenVPN, however many firewalls do
not play nice with the necessary ICMP "fragmentation needed but
DF set" messages.

OpenVPN has a useful option --mssfix which allows you to specify an
upper bound on UDP tunnel packet size.  OpenVPN will then rewrite
the MSS on TCP SYN packets flowing through the tunnel so that the
TCP senders themselves will regulate themselves down to
within the no-fragmentation threshold.

>> b) I still have a problem with the term "SSL/TLS VPN".

>What is an "SSL VPN"?  A web application that runs over TLS? 8-)

>Uh-oh, it looks as if this joke isn't too far off.  This reminds me of
>the good old times when we tried to use TeraTerm and SSH port
>forwarding to secure a Baan installation.

>> What OpenVPN seems to do is use SSL for authentication and key
>> exchange/rekeying, but does use "ESP similar" data protection
>> schemes/formats. Does the usage of SSL on a "control plane" make
>> OpenVPN an "SSL VPN"?

>No, it certainly isn't.  OpenVPN doesn't work at the application
>layer, as SSL VPNs usually do.  It's a real VPN, and you can choose
>between layer 2 or layer 3 operation.

>> This sounds to me like calling something a car just
>> because it uses a steering wheel... So far I thought
>> about SSL VPNs as doing everything over SSL (with
>> the known disadvantages...).

>At least OpenVPN uses a bit SSL and provides a VPN.  SSL VPNs use a
>lot of SSL, but provide no VPN.

When OpenVPN is represented as being an SSL VPN, it is meant
literally, not in the marketing sense of seeking to elevate the
credentials of a web application.

OpenVPN is a real VPN which uses SSL/TLS for session authentication.
It's a real VPN in the sense that IP or ethernet frames from a virtual
network interface are being encrypted, encapsulated in a carrier
protocol, and tunneled.  It's an SSL/TLS VPN in the sense that SSL/TLS
is the authentication mechanism.  It's not an SSL VPN in the sense of
being a web application.  In fact it might be more appropriate to
distingush web-app VPNs by calling them HTTPS VPNs, since they are
distinguished by their ability to use a web browser as the client.
OpenVPN is an SSL/TLS VPN but not an HTTPS VPN.

There's more to it than that of course.  OpenVPN uses the basic
components of IPSec ESP to secure the actual tunnel datagrams:
Explicit IV, HMAC integrity checking, and replay protection.
But that's the easy part.  The difficult part of any security protocol
that can't rely on preshared secrets is getting the authentication
right.  And to say that OpenVPN is an SSL VPN is an attempt to
emphasize that point.

Looking forward, it's quite possible that DTLS (Datagram TLS) will
establish itself as the solution to the problem that the OpenVPN
protocol is trying to solve, so I expect migration in that direction.

James


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to