* 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
