Introduction:
OpenVPN
is a newer generation VPN in that it is based on SSL as the underlying security
mechanism. IPSEC is the current and most popular standard for VPN technology.
SSL is already a standard for secure communication over the Internet for financial
transactions, checking email, and ensuring sensitive information is not leaked
to "people-in-the-middle". Many articles I've read speak of SSL VPN's as requiring
a browser. I'm not sure why that gets under my skin. It just isn't true. The
only time I use a browser over OpenVPN is to access an intranet web server
on the remote side. Once an OpenVPN tunnel is established you can then use
any application to access services on the remote end, provided the right access
controls are in place. A browser is not needed to create an OpenVPN tunnel,
it can be done from the commandline. Another nicety is that it runs on Windows
20000/XP, Linux, Solaris, FreeBSD, OpenBSD, NetBSD, and MacOS X.
Oh yes,
and it is under the GNU Licenese. OpenVPN uses the protocols that are available
with SSL and TLS 1.0 for authentication, encryption, and intergrity checking.
I have personally tested and use OpenVPN on Windows and Linux systems. I've
never had problems using any applications over OpenVPN. The only issue I've
run into is a common or well-known issue with VPN's and that is the problem
with packet fragmentation, which is easily remedied by a simple OpenVPN configuration
option.
Don't let
the SSL scare you because of creating public and private keys. OpenVPN comes
with scripts to automate the process (If you ask nicely, I'll send you my
scripts to automate the process even more.) You'll also want to ensure the
client's key expires within a reasonable amount of time and require a password.
Also, OpenVPN supports static keys which is good for LAN-to-LAN connections.
It can be a bit scary letting remote users have a static key out in the wild,
so a public/private key exchange is best for remote users. Static keys should
be changed very often (Note: OpenVPN static keys that are created on Windows
can be used on Linux and vice versa. Remember the dos newline issue if you
are creating and sending keys between unix and windows systems.)
Interview with
James Yonan, Creator of OpenVPN:
LinuxSecurity.com: What browser is required
to run OpenVPN tunnels?
James
Yonan: Talking about SSL VPNs doesn't necessarily mean that you are
talking about a VPN which uses a web browser as the client. In a sense, browser-based
VPNs are not VPNs at all -- they are really just web applications that provide
enough services so that a true VPN is not actually required.
OpenVPN
uses the underlying cryptographic mechanism of SSL/TLS to secure a VPN connection,
but the web analogy stops there. OpenVPN can best be understood as a portable,
user-space VPN implementation which uses SSL/TLS as its underlying cryptographic
engine. OpenVPN is able to use the same public key infrastructure as Apache,
but is otherwise not related to the secure web.
LinuxSecurity.com:
What do you do in your spare time?
James
Yonan: Open Source development, jazz dancing, and flying (without
an engine).
LinuxSecurity.com:
How did the idea to create OpenVPN come about?
James
Yonan: Around the turn of the century, I finished up a large project
for my company. As a kind of thank you, they decided to unchain me from my
workstation, on the condition that I maintain an always-reachable telepresence.
With this newfound freedom, I traveled all over the world, checking into the
office from places like Hurghada Egypt, and Bishkek Kyrgyzstan. As one might
imagine, I become very interested in the tools of telecommuting. I wanted
a solution that was not only world-class from a security perspective, but
that would also give me the ability to install and manage the remote end of
the VPN, without needing to bother people back at the office. Traveling in
Central Asia (pre 9/11), I was especially concerned about active attacks and
connection hijacking, since my internet path crossed through Russia and other
regions having an absurd number of very talented hackers who were also unemployed.
My initial
foray into Linux VPNs showed that the various VPN camps had split into groups,
based on the kind of tradeoffs they were willing to make. The "security-first"
group consisted of the IPSec and FreeSwan people whose goal was to first get
the security right, sometimes at the expense of robustness and usability.
Then there were the non-IPSec camps (VTun, Cipe, etc) founded by people who
probably needed a VPN right away and decided it would be easier to roll their
own than figure out how to install IPSec. The non-IPSec camps were very focussed
on the networking theory behind VPNs, and I think a major innovation that
came out of this work was the concept of the "tun" or "tap" virtual network
adapter as a means of moving the complexity of the VPN into userspace, logically
separating the networking and crypto components, making the code portable,
and giving an intuitive interface to the end-user (tun or tap drivers export
a first-class network interface to the OS which can be routed from/to, firewalled,
NATed, just like any other interface).
After some
study of the open source VPN field, my conclusion was that the "usability-first"
camp had the right ideas about networking and internetwork tunneling, and
the SSH, SSL/TLS, and IPSec camps had the appropriate level of seriousness
toward the deep crypto issues. This was the basic conceptual starting point
for my work on OpenVPN.
LinuxSecurity.com:
How did you choose the name OpenVPN?
James
Yonan: OpenVPN is tightly coupled with the OpenSSL library, and given
OpenVPN's tendency to inherit stuff from its dependencies, sharing 4 out of
7 name characters seems appropriate.
The other
thing I like about "OpenVPN", is that the name makes it immediately clear
what the whole production is about.
LinuxSecurity.com:
Why use SSL?
James
Yonan: Establishing a cryptographic handshake over an insecure network,
in a way that is resistant to connection hijacking, is one of the most challenging
problems in cryptography.
The fact
that we have 3 versions of SSL + TLS 1.0 should clue you in to the fact that
cryptographers seem to take delight in attempting to outsmart themselves by
devising ever-better protocols and then smashing them in their spare time.
Ever heard of of SSL 1? It was apparently cracked in real-time as it was being
presented at a cryptographic conference. Who knows how many other cryptographic
schemes would be similarly broken, were they exposed to any real scrutiny?
TLS fits
the bill rather nicely. It is a high-quality piece of cryptographic work,
designed, attacked, and ultimately endorsed by some of the brightest cryptographers
today.
It is also
easily accessible in userspace library implementations, such as OpenSSL.
LinuxSecurity.com:
Many VPN appliances and software applications are billed as "IPSEC-compliant",
yet many aren't compliant. Can SSL-VPN's be made compliant eg. for example with
Amrita VPN? ( http://amvpn.sourceforge.net
)
James
Yonan: Ever since Peter Gutmann published his critique on open source
VPNs, there has been growing interest in putting together an RFC to describe
a TLS-based, user-space VPN standard.
I expect
that this process will take time, more so because of usability and management
issues than security issues. User-space VPNs have already reached the point
where they are stable, secure, and well-documented. What is still needed is
to make them easier to configure both at the low end (new users, small business,
home offices) and higher end (larger organizations with potentially hundreds
or thousands of VPN users).
While we
know today the kinds of cryptography technology a VPN needs to be secure,
we don't really know yet what the optimal VPN experience should look like,
from a usability perspective. How do we minimize the amount of manual configuration
required? How do we streamline the key management process? I would argue that
it would be premature to codify the user-space VPN model into a standard until
we have a better handle on the usability and management issues.
LinuxSecurity.com:
What kind of security problems do "compliant" VPN's introduce?
James
Yonan: One of my major gripes with IPSec is that it adds a lot of
complexity to the kernel. Complexity is really the enemy of security. The
problem with putting complex security software in the kernel is that you ignore
an important security principle: never design secure systems so that the failure
of one component results in a catastrophic security breach. A single buffer
overflow exploit in kernel space results in total system compromise -- why
not move the complexity into user space where the code might run in an empty
chroot jail as user "nobody"? At least with this approach, a code insertion
exploit can be more readily contained.
LinuxSecurity.com:
How do we spread the word on SSL-VPN's?
James
Yonan: The best thing you can do is try one, and report your experiences
(good or bad) back to the community.
LinuxSecurity.com:
James, thank your for your time. We appreciate the interview!
Duane
Dunston is a Senior Computer Security Analyst at STG
Inc. for the National Climatic Data Center
in Asheville, NC. He received his B.A. and M.S. degrees from Pfeiffer
University and he has his GSEC certification from SANS.
He writes poetry. He hangs out at Anntony's, Early Girl Eatery (tell'em Duane
sent you), The New French Bar, and still wakes up every morning ready to go
to work.
<
