The Security of Open Source Software Myth, an Opinion

For many years, people have espoused that Open Source Software (OSS) is inherently more secure and more trustworthy than closed source software (CSS).  There are people whose whole lives are built around this concept as a crusade, and we’ve experienced our fair share of heckling from the crowd over the fact that there is plenty to VyprVPN that is closed source.

As a company, we certainly support the advancement of OSS.  It has enabled us to successfully provide Internet-based services in many online marketplaces for over two decades.  We were among the early pioneers starting ISPs back in 1994.  Without the early OSS movement providing the software behind the myriad Internet services of the day, none of those early ISPs would have been successful.  I’d wager that without the early OSS movement, the Internet today would still be a closed environment like Prodigy and CompuServe from our past.  OSS software has served and continues to serve as enablers for the advancement of economic growth.

The last two years have certainly given the concept that OSS is more secure a run for its money.  Core, key components to critical, modern OSS have been hit extremely hard with devastating security vulnerabilities.  Heartbleed in OpenSSL, Shellsock in bash, and the getaddrinfo defect in glibc have been revealed to have years-long security vulnerabilities with high potential for remote exploitation.  These security vulnerabilities, in existence for years, visible to any who would cares to look, but only recently exposed, should give everyone pause.  Linux, our favorite OSS operating system, and a large amount of supporting OSS that runs atop it, is no more or less secure than any other modern operating system.

There are two areas where OSS wins hands down over CSS: The first is in my ability to see what the software is doing by inspecting the code.  However, there are plenty OSS codebases where the developers thought obfuscation was more important than readability – or, at least, I hope that’s what they were thinking.  Second, because I have the code and I can compile it myself, OSS is better at letting me alter the behavior of the program to suit my needs.  These two things are virtually impossible with CSS.

A gray area in this debate is whether or not OSS can fix security vulnerabilities faster than CSS.  It certainly stands to reason that once a security vulnerability is known, anybody can get in there and submit a fix.  The reality of this month’s (February 2016) glibc vulnerability (CVE-2015-7547) was registered with cve.mitre.org on September 29, 2015, but was only publicly announced and fixed on February 16, 2016, with some distributions not getting fixes released until February 17th.  I’m not certain why a security defect of this magnitude took 4.5 months to resolve.  It certainly points out that OSS is not a panacea of fast response times for security vulnerabilities.

Is it easier to find security defects in OSS because we can see and inspect the code?  Likewise, is it more difficult to do the same in CSS because we cannot see the code?  I don’t believe history has shown these assumptions to be true.  For example, the glibc vulnerability we just experienced was discovered through developers using the library with defective code; it was not through a proactive investigation of the defective code.  The Shellshock vulnerabilities of bash existed in the open source code base since September 1989; its discovery would wait until September 2014 – 25 years!  Further, if the closed nature of CSS made discovery of security vulnerabilities hard, then we would not have the regular stream of security updates as we do from Microsoft and Apple; the open nature of OSS likewise has not prevented a similar stream of regular security updates from all of our favorite Linux distributions.

On the flip side, Apple’s current fight with the department of justice gives me confidence that CSS is not equivalent to insecure.  In fact, because the US Government is going to Apple with this demand tells me that the US Government is incapable of defeating Apple’s encryption.  Further, Apple’s response demonstrates that businesses who engaged in business through the means of CSS can still be on the right side of privacy and security.  Like Apple, we continue to fight against the overreach of government and we will continue to provide services which enable you to be safe and secure in your online activities.  For the last two decades, we have been engaged in these political struggles, and we will continue to be.  It’s in our blood.  Take Back Your Internet!

VyprVPN Server – Where does it stand with respect to Open Source Software?

I think that’s enough of an opinion piece for ‘OSS vs. CSS: Who’s more secure’.  Let’s move to answering the question we really care about here: Where is VyprVPN Server with respect to OSS?

First, VyprVPN Server is based on Ubuntu Server 14.04 LTS (an open source Linux server distribution).  From Ubuntu we are using the following open source software packages for various needs: bash, python, a bunch of OSS python modules, pppd, cloud-init, openvpn, xl2tpd, openssl, openssh, nginx, curl, and sha256sum (among others!).  We’re downloading and compiling a more recent version of strongswan, another piece of OSS.  We’re installing docker, an OSS container software, directly from their package repositories.

A key understanding for VyprVPN Server is that the VPN protocols are being supplied by the following, unmodified, open source software:

• OpenVPN-160, OpenVPN-256, and Chameleon connections: OpenVPN
• IPSec for iOS connections: Strongswan
• L2TP/IPSec (coming in 0.11): Strongswan, xl2tpd, and pppd

So what is closed source in VyprVPN Server?

The glue that makes it all work.  Our web interface and the services that run on the box providing the Administrative CLI and Administrative Web interfaces.  The glue we wrote to take the configurations done in these administrative interfaces and apply them to the configuration files of the myriad open source software packages.  The glue we wrote to talk with our API servers to register your server with your account so that it shows up in your VyprVPN mobile and desktop applications seamlessly.  It’s the glue that takes this unconfigured OSS and makes it work in the VyprVPN ecosystem.  This is the glue that gives us a competitive advantage in the marketplace, and that enables us to continue development of this and other products for our customers.  To give you a clear picture of what’s closed vs. what’s open source in VyprVPN Server, the closed source glue makes up 0.7% of the bytes in a deployed VyprVPN Server 0.10.0.114 instance.

What about Chameleon?

I make a case above that the bulk of the closed source code above is glue that doesn’t get involved in the VPN connectivity at all.  Let’s talk about the one piece of closed source software in VyprVPN Server (as well as the VyprVPN applications and our public servers) that does get involved in the VPN connection, and maybe it does deserve some thought about open sourcing:  Chameleon.

This isn’t the first time it’s been thought about either – others have given it some thought and have even provided some strong opinions.  Here are a few for your pleasure (Google can find you many, many more):

1. http://www.vpnspblog.com/vyprvpn-chameleon/
2. http://www.wilderssecurity.com/threads/ways-to-obfuscate-vpn-connections.363059/
3. https://gigaom.com/2014/01/27/vyprvpn-provider-starts-using-proprietary-chameleon-protocol-for-anonymity/

Let’s make sure we understand how Chameleon works:

• Chameleon works by having a “proxy process” on the client and the server (look, no violation of the OpenVPN’s GPL).
• This process takes the packets OpenVPN is sending across the wire and adds obfuscation; It takes the packet OpenVPN provides and it performs bit-scrambling to prevent deep packet inspection (DPI) from detecting it as an OpenVPN connection.
• It does NOT add encryption or security, and it does NOT replace or change the encryption performed by the underlying OpenVPN connection.

The important takeaway here is that Chameleon is NOT a piece of security software and it doesn’t need to be open source for you to see that it doesn’t do nefarious things.  You can fully inspect the way our applications configure OpenVPN (go look at the configuration files) to connect through it and you can use system tools (strace, tcpdump, etc.) to watch OpenVPN send the packets, Chameleon read them, and then Chameleon sends them on to the remote server.  Now with VyprVPN Server, you can see how we funnel OpenVPN connections into the Chameleon proxy, and using system tools (strace, tcpdump, etc.) you can watch it read packets from clients, and watch it send those packets to the OpenVPN process running on the device.  Now with a client and a server you can actually see and verify that the raw OpenVPN packets sent from the client are the same packets received by the server (if you find a discrepancy let us know, as that’s a bug!).

The second referenced link above has a poster quipping that perhaps the closed source nature of Chameleon is “security through obscurity.”  This poster couldn’t be more in-sync with what’s going on here.  Quite literally if we open sourced the implementation of Chameleon it would take DPI authors literally no time at all to defeat it.  They’d know exactly how we perform the obfuscation and the game would be up.  The only thing I would change is to make it read: “Chameleon’s closed source nature is obfuscation by obscurity.”  To open source Chameleon would be to defeat the very purpose for which it’s been written.

In Summary

VyprVPN Server is 99.3% Open Source Software.  The 0.7% of the Closed Source Software is the glue that configures all of the open source software.  You’re free to look about at the configurations our glue produces; the configuration files have to be in plain view so the software can read them.  Chameleon makes up a small part of that 0.7%, and it remains closed because opening it would defeat the very purpose.  Chameleon is open enough on both client and server systems for you to investigate its behavior.  OpenVPN, Strongswan, xl2tpd, and pppd (the processes that provide the VPN connections) are all used in an unmodified, unadulterated, Open Source Software, form.  You can go launch a VyprVPN Server instance, register it with your account, and go poke about the system.  The system is open for anyone who wants to verify my statements.