For many years, people have embraced the Open Source Software (OSS) is inherently more secure and more reliable that closed source software (CSS). There are people whose entire lives are built around this concept as a crusade, and we had our share of heckling from the crowd on the fact that there is much to VyprVPN is closed source.
As a company, we certainly support the promotion of OSS. It has enabled us to successfully deliver Internet-based services in many online markets for over two decades. We were among the first pioneers from the FAI in 1994. Without early OSS movement providing the software behind Internet services myriad of day, none of the first Internet service providers have been successful. I bet no movement OSS first Internet still is a closed environment like Prodigy and CompuServe our past. OSS has served and continues to serve as facilitators for promoting economic growth.
The last two years have certainly given the idea that OSS is more secure a run for its money. Core critical key elements, modern SOAs have been hit hard with devastating security breaches. Heartbleed in OpenSSL, Shellsock in bash, and failure to getaddrinfo in glibc have been shown to have many years of security vulnerabilities with potential for remote operation. These security flaws, in existence for years, visible to all who would care about watching, but only recently exposed, should give everyone pause. Linux, our preferred operating system OSS, and a large amount of OSS support, which works above, is more or less secure than any modern operating system.
There are two areas where OSS is gaining hold of CSS: the first is in my ability to see what the software is doing by inspecting the code. However, there are plenty codebases where OSS developers thought darkening was more important than readability - or, at least, I hope that what they were thinking. Second, because I need the code and I can compile myself, OSS is better to let me change the behavior of the program to suit my needs. These two things are practically impossible with CSS.
A gray area in this debate is whether or not OSS can fix security vulnerabilities more quickly than CSS. It certainly goes to reason that once a security vulnerability is known, everyone can enter and submit a patch. Reality (February 2016) glibc vulnerability this month (CVE-2015-7547) was recorded with cve.mitre.org September 29, 2015, but has been publicly announced and set February 16, 2016, with some distributions do not get patches released until February 17. I'm not sure why this scale security breach took 4.5 months to resolve. It certainly recalls that OSS is not a cure-fast response time for security vulnerabilities.
Is it easier to find security flaws in open source because we can see and inspect the code? Likewise, is it harder to do the same in CSS because we can not see the code? I do not think history has shown that these assumptions to be true. For example, the vulnerability of glibc we just experienced was discovered by developers using the library with the defective code; it was not through a proactive investigation of the defective code. The bash Shellshock vulnerabilities exist in the open source code base since September 1989; his discovery would wait until September 2014 - 25 years! Also, if the closed nature of CSS made the discovery of difficult security vulnerabilities, then we not have the steady stream of security updates as we do from Microsoft and Apple; the open nature of the OSS same did not stop a similar flow of regular security updates to all of our favorite Linux distributions.
On the flip side, the current fight Apple with the Justice Department gives me the confidence that CSS is not equivalent to insecurity. In fact, because the US government will Apple with the request said that the US government is unable to defeat Apple's encryption. In addition, Apple's response shows that companies that engage in business through the means of CSS can still be on the right of privacy and security. Like Apple, we continue to fight against the excessive reach of the government and we will continue to provide services that allow you to be safe in your online activities. For the past two decades, we have been engaged in the political struggle and will continue to be. It is in our blood. Take Back Your Internet
VyprVPN Server - Where stand in relation to Open Source Software
I think it's just an opinion piece for !? OSS vs CSS: Who is more secure. " Now to answer the question we really care about here: Where is VyprVPN server compared to OSS
First, VyprVPN Server is based on Ubuntu 14.04 LTS Server (an open server source Linux Distribution). Ubuntu, we use the open following source software for various needs: bash, python, a lot of OSS python modules, pppd, cloud-init, OpenVPN, xl2tpd, openssl, openssh, nginx, curl and sha256sum (among others!). We download and compile a newer version of strongswan, another piece of the SOA. We install docker, a container OSS software directly from their package repositories.
A key understanding for VyprVPN Server as VPN protocols are provided by the following unmodified, open source software
- OpenVPN-0, OpenVPN-256, and Chameleon connections: OpenVPN
- iOS IPSec connections: strongSwan
- L2TP / IPSec (coming in 0.11): strongSwan, xl2tpd and pppd
So what is the source closed in VyprVPN server
the glue that does all the work. Our web interface and the services that run on the box providing the administration CLI and Web interfaces of Directors. Glue, we wrote to make the configurations made in these administrative interfaces and apply them to multiple open source software configuration files. The glue we have written to speak with our API servers to register your server with your account so that it appears in your mobile applications and seamlessly VyprVPN office. It is the glue that makes this unconfigured OSS and operates in the VyprVPN ecosystem. This is the glue that gives us a competitive advantage in the market, and allows us to continue the development of this and other products for our customers. To give you a clear picture of what is closed to what is open source in VyprVPN Server, glue closed source represents 0.7% of the bytes in a deployed instance VyprVPN Server 0.10.0.114.
What Chameleon?
I make a case above that most of the closed source code above is the glue that is not involved in VPN connectivity to all. Talking about a source software piece in closed VyprVPN Server (and the VyprVPN applications and our public server) that participate in the VPN connection, and perhaps it deserves a reflection on open sources :. Chameleon
This is not the first time he was thought to be - others gave some thought and even provided strong opinions. Here are some for your pleasure (Google you can find many, many more):
- http://www.vpnspblog.com/vyprvpn-chameleon/
- http: / /www.wilderssecurity.com/threads/ways-to-obfuscate-vpn-connections.363059/
- 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 server (look, no violation of LPG OpenVPN) .
- This process takes OpenVPN packets sent through the wire and adds obscuration ; He takes the OpenVPN package provides and performs scrambling bit to prevent deep packet inspection (DPI) detection as a OpenVPN connection.
- There NO add encryption or security, nor NO replace or modify the encryption performed by the underlying OpenVPN connection.
the important delivery here is that Chameleon is NOT a piece of security software and it does not need to be open source for you to see that this is not the infamous things. You can completely inspect how our applications configure OpenVPN (go watch the configuration files) to connect through it and you can use system tools (strace, tcpdump, etc.) to watch OpenVPN send packets, read the Chameleon and Chameleon sends them to the remote server. Now with VyprVPN Server, you can see how we funnel OpenVPN connections in the proxy Chameleon, and using system tools (strace, tcpdump, etc.), you can watch the read customer packages, and watch the send these packets the OpenVPN process running on the device. Now with a client and a server, you can see and verify that packets of raw OpenVPN sent by the client are the same packets received by the server (if you find a difference let us know, because it's a bug! ).
The second link referenced above has a poster quipping that maybe the nature of the closed source Chameleon is "security through obscurity." This poster could not be more in line with what happening here. literally if we open source implementation of IPR should Chameleon authors literally no time to defeat him. They know exactly how we achieve the darkening and the game would be up. the only thing I would change is to read ". The nature of the closed source Chameleon is obfuscation through obscurity ". To open the Chameleon source would defeat the very purpose for which it was written
In summary
VyprVPN server is 99.3% Open source software the 0.7% source software is the glue that closed sets all open source software You are free to look around in our product configurations glue;.. the configuration files must be in plain view so that the software can read it. Chameleon is a small part of this 0.7%, and it remains closed because of the open would defeat the very purpose. Chameleon is enough open on both client and server systems for you to investigate his behavior. OpenVPN, strongSwan, xl2tpd and pppd (the processes that provide VPN connections) are all used in a pure unmodified software, open source form. you can go run an instance VyprVPN Server, register with your account, go and sew on the system. The system is open to all those who want to check my statements.
0 Komentar