OpenVPN: An Introduction and Interview with Founder, James Yonan

In this article, Duane Dunston gives a brief introduction to OpenVPN and interviews its founder James Yonan.


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.

from   http://www.linuxsecurity.com/content/view/117363/49/