Would FLOSS benefit from standards? And vice versa - would standards benefit from FLOSS?10. Jul '14

Introduction

This is term paper written for Open Source and Intellectual Property in Digital Society course during summer of 2014 while I was studying at Technical University of Berlin. In the paper I will be discussing how Free and Open Source Software benefits from standards and vice versa. The topics focus on technologies used to secure communications over the internet. In 2003 Peter Gutmann, recognized computer scientist in the Department of Computer Science at University of Auckland published a lengthy article on the shortcomings of various VPN implementations for Linux 1 and that was a very good starting point for current work, however many things have changed meanwhile. I am going to dissect open-source projects like OpenSSL, OpenSSH, OpenVPN, StrongSwan and their relation to development of standards like SSL, TLS, IPsec, IKE, RSA. The examples are based on personal experiences with mentioned projects and standards.

1: https://www.cs.auckland.ac.nz/~pgut001/pubs/linux_vpn.txt

ARPANET

Modern Internet would not be possible without standards initially designed for Defense Advanced Research Projects Agency (DARPA) by Information Sciences Institute of University of Southern California originally prepared in September of 1981:

RFC 768: User Datagram Protocol
RFC 791: Internet Protocol (IP)
RFC 792: Internet Control Message Protocol (ICMP)
RFC 793: Transmission Control Protocol (TCP)

Following RFC-s also reflect key protocols:

RFC 894: A Standard for the Transmission of IP Datagrams over Ethernet Networks
RFC 826: An Ethernet Address Resolution Protocol (ARP)
RFC 1035: Domain Names (DNS)
RFC 2131: Dynamic Host Configuration Protocol (DHCP)

This list is of course comprehensive and it omits complementary standards and pretty much anything that has something to do with signaling either on the wire or optics. It's just to illustrate that moving bits from point A to B is complex task.

Symmetric ciphers

Symmetric cipher is one of the oldest concepts of cryptography. It requires all parties involved in the communication to have the same key in order to decipher transmitted ciphertext. Symmetric ciphers could be traced back to Caesar Cipher used by the Roman ruler Julius Caesar. The Enigma machine used by the Germans during the Second World War also constitutes as an implementation of symmetric cipher. The Germans however used complex key management system which made it significantly harder for the Allies to crack it.

As digital computers emerged in 70's so did symmetrical ciphers for such devices. Data Encryption Algorithm (DEA) which later became known as Data Encryption Standard (DES) 2 goes back to 1970. It was approved as federal standard in November of 1976 despite criticism 3. Later to combat the weaknesses Triple-DES 4 was conceived which basically ran the algorithm three times with different keys, but it did not make any fundamental changes to the algorithm.

In 1997 National Institute of Standards and Technology of US started looking for a successor for the aging DES. The update was required because DES with it's relatively short 56-bit key became vulnerable to brute force attacks. Initially NSA wanted to introduce controversial SkipJack algorithm 5 6, but later open and transparent decision process was adapted. The algorithm selection between 1997 and 2000 became to known as AES (Advanced Encryption Standard) process.

In 1998 Belgian cryptographers Joan Daemen and Vincent Rijmen, submitted their algorithm what they had named Rijndael cipher. Several other algorithms were submitted and the selection process was carried out in an open and transparent manner. Rijndael scored the highest and on 26th November 2001 it became official Advanced Encryption Standard (AES) 7 as announced by NIST.

2: http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf
3: http://www.toad.com/des-stanford-meeting.html
4: https://www.princeton.edu/~achaney/tmve/wiki100k/docs/Triple_DES.html
5: Crypto: How the Code Rebels Beat the Government Saving Privacy in the Digital Age by Steve Levy
6: http://jtlp.org/vol2/masson.html
7: http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf

Public-key cryptography standards

In 1977 Ron Rivest, Adi Shamir and Leonard Adleman descibed algorithm at MIT which became known as RSA algorithm. RSA algorithm is based on the integer factorization problem and it is one of the first asymmetric cyptography algorithms as the keys are split into two: private key and public key. On 20th September 1983, MIT was granted U.S. Patent 4,405,829 for the algorithm with an expiration date of 20th September, 2000. RSA Security had royality-based licensing policy. In the U.S. a license was required to "make, use or sell" products that incorporated RSA algorithms. However, RSA Security permitted free non-commercial use of RSA algorithm, with written permission for academic purposes 8. RSA Encryption v1.5 was published as a memo for the Internet community already in 1998 9. On 6th of September, 2000 RSA Security made the algorithm available to the public and waived it's rights to enforce patent. It officially became IETF standard in 2003 with the release of specification version 2.1 under the name of PKCS#1 10.

The Public-Key Cryptography Standards (PKCS) are standards defined by RSA Laboratories in cooperation with secure systems developers worldwide for the purpose of accelerating the deployment of public-key cryptography. First published in 1991 as a result of meetings with a small group of early adopters of public-key technology, the PKCS documents have become widely referenced and implemented. Contributions from the PKCS series have become part of many formal and de facto standards:

PKCS#1 (RFC 3447): RSA Cryptography Specification (v2.1)
PKCS#3 (RFC 2631): Diffie–Hellman Key Agreement Standard
PKCS#5 (RFC 2898): Password-Based Cryptography Specification (v2.0)
PKCS#7 (RFC 2315): Cryptographic Message Syntax (v1.5)
PKCS#8 (RFC 5208): Private-Key Information Syntax Specification (v1.2)
PKCS#9 (RFC 2985): Selected Object Classes and Attribute Types (v2.0)
PKCS#10 (RFC 2986): Certification Request Standard (v1.7)
PKCS#11: Cryptographic Token Interface Standard
PKCS#12: Personal Information Exchange Syntax Standard
PKCS#15: Cryptographic Token Information Format Standard (v1.1)

Later standards to complement PKCS#1 were added. For instance Estonia has been issuing PKCS#11 compatible hardware tokens in the form of a national ID-card for authenticating in Estonian e-banks and e-government and also for digitally signing documents. The Estonian law states that digital signature has to be considered legally equal to written signature 11.

8: http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/is-rsa-patented.htm
9: RFC 2313 RSA Encryption v1.5
10: PKCS#1 (RFC 3447): RSA Cryptography Specification (v2.1)
11: https://www.riigiteataja.ee/en/eli/ee/Riigikogu/act/530102013080/

Transport Layer Security

Transport Layer Security (TLS) previously also known as Secure Sockets Layer (SSL) is a protocol which is used to secure traffic over the Internet by means of encryption and mutual authentication. The protocol originates from Netscape. The first version also known as SSL v1.0 was never released by Netscape. The second version was released but it had serious security flaws which led to development of SSL v3.0 which has enjoyed broad adoption by banks and other organizations with tight security requirements. The name change from SSL to TLS also signifies the shift from Netscape to IETF. TLS formalizes use of hashing algorithms 13 14 15 in conjunction with the same aforementioned public-key cryptography standards and symmetric ciphers in order to provide a security subsystem which ensures authentication, non-repudiation, confidentiality, and integrity of user communications.

Standards associated with Transport Layer Security:

RFC 2631: Diffie-Hellman Key Agreement Method, released in 1999
RFC 6347: Datagram Transport Layer Security (DTLS) v1.2
RFC 5246: The Transport Layer Security (TLS) Protocol v1.2
RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
RFC 3268: Advanced Encryption Standard (AES) Cipher Suites for Transport Layer Security (TLS)
RFC 4132: Addition of Camellia Cipher Suites to Transport Layer Security (TLS)
RFC 6176: Prohibiting Secure Sockets Layer (SSL) v2.0

Several standards have been deprecated because of security issues:

RFC 4347: Datagram Transport Layer Security (DTLS)
RFC 4346: The Transport Layer Security (TLS) Protocol v1.1
RFC 2246: The TLS Protocol v1.0
RFC 6101: The Secure Sockets Layer (SSL) Protocol v3.0, released on 18th of November, 1996
Secure Sockets Layer (SSL) v2.0, released in 1995
Secure Sockets Layer (SSL) v1.0, internally released at Netscape in 1994

HTTPS is a way of encapsulating HTTP traffic within a TLS tunnel 12 and it is present in all major web browsers such as Mozilla Firefox, Google Chrome, Internet Explorer, Safari and others where secures the path between a web browser and a web server. The root certificates present in web browsers enable authentication of remote servers via green highlight on the address bar and other security features. The way web browsers currently use certificate authority hierarchy has however caused a formation of rather monopoly market. The money flowing in the CA business does not prevent any of the root certificate vendors to sign a fake certificate which could be used to snoop on users. For instance Google discovered in December of 2013 that French Certification Authority ANSSI which is closely working with French Defence Agency has signed domain names belonging to Google effectively enabling tapping into traffic of GMail, Youtube, Google Docs, etc 16. Similar incident was published on 8th of July, 2014 when Google discovered that National Informatics Centre of India had done the same 17.

Note that since Cold War the US has imposed restrictions on various products and goods which was also one of the reasons why Netscape didn't ship with AES or other strong crypto algorithms 18. The Wassenaar Agreement was established in 1995 as a continuation to CoCom. Currently Canada, US, most Europe and Russian Federation have signed the agreement but it's up to individual country to implement legislation 19. Wassenaar Agreement specifies which products need license, for example dual-use technologies such as weapons, lasers, sattelite positioning systems (GPS), software defined radios (SDR) and cryptography are covered by Wassenaar 20. Until 2012 selling goods that used strong cryptography sych as symmetric cipher key lenghts longer than 56 bits or RSA keys longer than 512 bits required license. Public domain software such as open source projects were exempt from this regulation. The Wassenaar 2012 amendments also relaxed sale of mass market products which could contain strong cryptography and addressing the issues of intrusive surveillance technology 22. Bert-Jaap Koops maintains annual summary of international crypto controls which should give an up-to-date overview about restrictions across countries and enonomic unions 21.

12: RFC 2818: HTTP Over TLS (HTTPS)
13: RFC 1321: MD5 message-digest algorithm
14: RFC 6234: Secure Hash Algorithms (SHA)
15: RFC 2104: Keyed-Hashing for Message Authentication (HMAC)
16: Google Online Security Blog: Further improving digital certificate security
17: Google Online Security Blog: Maintaining digital certificate security
18: What is SGC?
19: http://www.cryptolaw.org/cls2.htm#Wassenaar
20: http://www.wassenaar.org/controllists/2013/WA-LIST (13) 1/08 - WA-LIST (13) 1 - Cat 5P2.doc
21: Summary of international crypto controls by Bert-Jaap Koops
22: International agreement reached controlling export of mass and intrusive surveillance technology

OpenSSL

SSLeay was a SSL implementation written by Eric Young so as to conform to Netscape SSL specification. Eric Young and Tim Hudson founded a security consulting firm Cryptsoft around SSLeay 23. In 1999 Eric and Tim joined RSA and and turned SSLeay into a commercial product 24. The community took off from the remaining codebase in 1998 and it became known as OpenSSL. Today OpenSSL is the mainstream implementation of TLS and also one of the most popular open-source general purpose cryptography libraries as it provides primitives for public-key crypto, symmetric ciphers and hashing algorithms.

On 21st of March, 2013 a Google engineer discovers serious vulnerability in OpenSSL implementation of TLS heartbeat protocol 25. On 7th of April, around two weeks later the vulnerability was published and it became known as Heartbleed 26. It is believed that around 2/3 of web servers around the world use OpenSSL to secure HTTPS connections. Unfortunately OpenSSL versions released since December on 2011 were affected and as of April of 2013 these versions constituted to the majority of the versions in use 27.

As the Heartbleed crisis was mainly blamed at lack of OpenSSL funding several corporations such as Facebook and Microsoft decided to put together framework for financing various open-source projects which contribute to the global Internet ecosystem. The project is managed by Linux Foundation 33. The Heartbleed controversy also resulted in two forks: LibReSSL led by Theo de Raadt aims at POSIX compatibility and removing redundant code 30. BoringSSL from Google serves similar purpose 31 32.

PolarSSL is a SSL library written in C tailored towards embedded systems as OpenSSL is pretty heavy. It began as an official fork of XySSL in 2008 and it is available either under GPLv2 license or a commercial license by a Dutch company Offspark B.V. 28. Dutch government is using a specially crafted version of OpenVPN which uses PolarSSL instead of OpenSSL 29. PolarSSL for instance was not affected by Heartbleed vulnerability.

23: About Cryptsoft
24: https://www.mail-archive.com/openssl-users@openssl.org/msg00873.html
25: RFC 6520: Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension
26: http://www.smh.com.au/it-pro/security-it/heartbleed-disclosure-timeline-who-knew-what-and-when-20140415-zqurk.html
27: http://www.troyhunt.com/2014/04/everything-you-need-to-know-about.html
28: https://polarssl.org/about-us
29: https://openvpn.fox-it.com/
30: http://marc.info/?l=openbsd-misc&m=140199662922801&w=2
31: https://www.imperialviolet.org/2014/06/20/boringssl.html
32: https://marc.info/?l=openbsd-tech&m=140332790726752&w=2
33: Core Infrastructure Initiative

OpenVPN

I can't remember when and why was my first experience using OpenVPN. Most probably I wanted to gain access to network services running on a server without opening up those services to the public Internet. Until now I've been using OpenVPN for several years. Since 2013 I have been conducting courses about firewalls and virtual private networks at Estonian Information Technology College funded by European Social Fund 34 and in the courses I've focused mainly on iptables/netfilter and OpenVPN. Until now I've taken OpenVPN for granted as a de facto standard for implementing virtual private networks. It is rich in features and it is reasonably simple to either connect subnets behind two routers or connecting laptops to a corporate network over Internet in a secure manner using OpenVPN.

In 2003 James Yonan, the creator of OpenVPN gave interview on www.linuxsecurity.com where he explained that back in 2001 while he was travelling in Central Asia with links travelling through Russia he became concerned about connection hijacking while accessing services over the Internet. On May 13th, 2001 the first public version of OpenVPN was released which could barely tunnel IP packets over UDP using Blowfish encryption and SHA HMAC signatures. After the release of version 1.0 on March 23rd, 2001 the development took off. In November of 2001 test bed was set up for OpenVPN 2.x which was initially prepared for multi-client server for OpenVPN. It continues to be one of the key features of OpenVPN. Looking back at the history of OpenVPN it is clear that before 2001 there was no VPN solution which would be easy to set up and at the same time would be reasonably secure 35.

OpenVPN builds on top of well established technologies such as Transport Layer Security, TUN/TAP API 36, DHCP 37, RSA certificates and X.509 PKI. Other than that it is a in-house developed standard. On the web they say it's a community effort but actually there is OpenVPN Technologies, Inc company behind the project who is selling premium services and tools that complement the core open-source project. Francis Dinha and James Yonan co-founded the company in Pleasanton, California to secure a solid foundation for OpenVPN and advance it's commercial potential 38. It is of course in their best interests to remain backwards compatible with previous versions but implementing competing codebase becomes much harder when there is no RFC to follow. After asking related question on OpenVPN community forums James responded that they're planning to create RFC detailing the OpenVPN protocol 39. Some protocol details might be found in the source code documentation 40. OpenVPN versions 1.x and 2.x have referred to two significantly different codebases, but the protocol and features have been kept backwards compatible. As a community effort the copyrights belong to all respective authors and until now OpenVPN has been released under GNU GPL license.

With the advent of smartphones demand for open-source VPN tools has increased. However being an GPL-licensed project has it's hurdles. In 2011 a Red Hat employee Jan Wildeboer discovered that Microsoft prevents GPLv3 licensed software distribution in Windows Phone 7 Marketplace, to be more precise any license that requires source code redistribution or compulsory right to produce derivative works is prohibited 41. Apple has similar issues with GPL. Every copy of an app downloaded from the Apple appstore is tied to a specific user account and this applies to free apps aswell. The GPL requires that any software using the license and it's derivative works remain freely copied and distributed, that is however not possible because of the DRM-like mechanisms Apple appstore imposes on the users. Popular video player VLC was removed in 2011 from Applet appstore because of the incompatibility between Apple appstore policies and GPL license 42. This has pushed OpenVPN Technologies to develop third iteration of the codebase which is C++ centric and complements the OpenVPN ecosystem 43 44. OpenVPN 3 is based on Boost libraries and it can be compiled against various SSL libraries such as: OpenSSL, PolarSSL and Apple Security/CommonCrypto API. OpenVPN 3 is licensed under AGPL3 license but as the codebase is owned by OpenVPN Technologies, Inc and they require Contributor License Agreement (CLA) they may relicense the software as they see fit which makes it possible to redistribute closed-source apps for iOS and Android.

IPsec

Internet Protocol Security also known as IPsec is a set of standards designed to complement Internet Protocol (IP) by providing mechanisms to authenticate and encrypt each IP packet transferred over potentially insecure network. IPsec operates on OSI layer 3 and it is mandatory in IPv6 whereas it is optional in currently widespread IPv4 45.

IPsec consists of several standards which have been released over the years:

RFC 2367: PF_KEY Interface
RFC 2403: The Use of HMAC-MD5-96 within ESP and AH
RFC 2404: The Use of HMAC-SHA-1-96 within ESP and AH
RFC 2405: The ESP DES-CBC Cipher Algorithm With Explicit IV
RFC 2410: The NULL Encryption Algorithm and Its Use With IPsec
RFC 2412: The OAKLEY Key Determination Protocol
RFC 2451: The ESP CBC-Mode Cipher Algorithms
RFC 2857: The Use of HMAC-RIPEMD-160-96 within ESP and AH
RFC 3526: More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)
RFC 3686: Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)
RFC 3706: A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
RFC 3715: IPsec-Network Address Translation (NAT) Compatibility Requirements
RFC 3947: Negotiation of NAT-Traversal in the IKE
RFC 3948: UDP Encapsulation of IPsec ESP Packets
RFC 4106: The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
RFC 4301: Security Architecture for the Internet Protocol
RFC 4302: IP Authentication Header (AH)
RFC 4303: IP Encapsulating Security Payload (ESP)
RFC 4304: Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)
RFC 4307: Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)
RFC 4308: Cryptographic Suites for IPsec
RFC 4309: Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)
RFC 4478: Repeated Authentication in Internet Key Exchange (IKEv2) Protocol
RFC 4543: The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH
RFC 4555: IKEv2 Mobility and Multihoming Protocol (MOBIKE)
RFC 4621: Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol
RFC 4806: Online Certificate Status Protocol (OCSP) Extensions to IKEv2
RFC 4809: Requirements for an IPsec Certificate Management Profile
RFC 4835: Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
RFC 4945: The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
RFC 5996: Internet Key Exchange Protocol Version 2 (IKEv2)
RFC 6071: IPsec and IKE Document Roadmap

Listed whopping 30+ standards have been published between 1998 and 2011. Apple iOS IPsec client was based on racoon which supported only IKEv1. With the release of iOS 8 support for IKEv2 has been implmemented which makes iPhone-s IPsec implementation stack modern 46.

45: Linux Foundation: IPsec overview by Rami Rosen
46: http://apple.stackexchange.com/questions/105268/does-ios-support-ipsec-ikev2

FreeS/WAN and it's descendants

FreeS/WAN was of the first open-source projects to partially support IPsec protocol suite. John Gilmore who is also co-founder of Electronic Frontier Foundation stated that his original goal in 1996 was to secure 5% of the Internet traffic against passive wiretapping by the end of the year using transparent opportunistic encryption and continue that trend until all of Internet traffic was encrypted by default. The first version was released on 14th of April 1999 63. FreeS/WAN consisted of a kernel module called KLIPS (Kernel Level IP Security) which enabled transformations of incoming/outgoing IP packets and Pluto the Internet Key Exchange (IKE) daemon.

KAME was a similar Japanese project spanning from 1998 to 2006 that intended to provide free IPsec implementations of IPv4 and IPv6 60 for BSD variants. KAME included kernel module very similar to KLIPS and an IKE daemon called racoon 61. IPsec-Tools project was an effort between 2006 and 2011 to port KAME to Linux based systems 62. Later Linux adopted KAME's kernel API (PF_KEY sockets) and compiling separate module was not necessary. FreeS/WAN implemented KAME API aswell so it could interact with older kernels with KLIPS and on newer ones via KAME API. Much later generic packet transformation subsystem called XFRM was added to the kernel. It also seems to be mostly written by Japanese as part of the USAGI project 50.

Andreas Steffen, a proffessor at the University of Applied Sciences in Rapperswil, Switzerland 51 provided patches for FreeS/WAN which enabled X.509 certificate based authentication for FreeS/WAN 53. X.509 is a standard for public key infrastructure (PKI) and privilege management structure (PMI) 47 and it's part of ITU-T X.500, which is a family of computer networking standards that cover electronic directory service. LDAP protocol used by Microsoft Active Directory also belongs to X.500 standard suite 48. X.509 specifies how public key certificates, certificate revocation lists (CRL), attribute certificates and certificate path validation should be handled. X.509 also specifies how certificate validity can be checked online using online certificate status protocol (OCSP) 49. The Public-Key Infrastructure (X.509) working group of IETF also known as PKIX was established in August of 1995 with the goal of developing IETF standards that would support PKI 52. PKIX has published dozens RFC-s In 2000 Peter Gutmann pointed out how vaguely the standards were defined 54.

FreeS/WAN folks were reluctant to add features that didn't contribute towards achieving the main goal which was ubiquitous opportunistic encryption and X.509 patch was one of such features. FreeS/WAN 1.98b released on 11. july 2002 in conjunction with Andreas' X.509 patches became known as Super FreeS/WAN for a brief time. It was later renamed to Openswan 1.0.0 which was released on 2nd of January 2004 55. FreeS/WAN project also had 2.x branch in development which updated the way configuration files were parsed. Openswan 2.0.0 was based on FreeS/WAN 2.04, Andreas patchset for 2.x branch and other bugfixes. Openswan also added NAT traversal support and AES encryption. FreeS/WAN derived its name from S/WAN, which is a trademark of RSA Data Security, Inc. RSA Data Security permitted the use of the trademark however derivates such as Openswan decided to avoid spelling SWAN in capital letters so they wouldn't have to face legal implications.

Eventually FreeS/WAN project was discontinued in 2003 without having achieved the goal of opportunistic encryption. Paul Wouters, a dutch developer based in Canada clarified on Freenode IRC that funding for FreeS/WAN had stopped and Gilmore wanted to remove features from FreeS/WAN which were already covered by RFC-s. Europe based developers also grew tired of "no American code" policy since US ban on export of cryptographic tools meant that distributing Canadian based FreeS/WAN with Amercian written code the software qualified as American dual use munition (eg weapons), which could lead to ban on distributing by the US at a whim, for example through the use of a National Security Letter, or further export restrictions.

Gilmore and Wouters met at Chaos Communication Congress summer camp 2003 in Paulshof, near Berlin. There they came up with forking plan so FreeS/WAN community members and other volunteers represented by Wouters could continue as Openswan and Gilmore could rip out features that he didn't find interesting.

Most of FreeS/WAN community members such as Wouters himself, Ken Bantoft, Michael Richardson, Hugh Daniel and Tuomo Soini founded Openswan with the purpose of having open-source IPsec implementation in addition to FreeS/WAN's opportunistic encryption goal. Richardson wanted to keep Openswan modular so features such as X.509 support could be toggleable during compile time as it was important for resource constrained devices such as routers. Initially Steffen was planning to join the Openswan project, but as he got in an argument with Richardson about his X.509 code being toggleable via #ifdef macros he eventually decided to create StrongSwan which has grown to be one of the most recognized open-source enterprise IPsec stacks.

Wouters, Richardson, Bantoft and Daniel founded Xelerance Corporation in 2003 to support Linux open source security products, focusing on Openswan 56. Wouters worked there as Openswan release manager 57. Xelerance changed its focus after few years. Daniel and Bantoft left the company early, followed by Richardson in 2008. When Wouters left in 2011, Xelerance laid claim to Openswan by suing Wouters. Eventually ownership of "Openswan" was transferred to Xelerance including the trademark, domain name and mailinglists 58.

While Wouters was trying to come up with a mutually acceptable solution with Xelerance, the Openswan developers moved their development to their own private servers as none were left at Xelerance. When it became obvious that no reasonable settlement would be reached, the codebase was renamed and publicly released as Libreswan. Openswan is now critisized of lagging behind with updates since the Openswan community is non-existant and Xelerance can't keep up with the updates 59.

FreeS/WAN and it's descendants

Richardson actively participated in the IETF workgroups and wrote several RFC-s which contributed to the development of DNSSEC standards such as A Method for Storing IPsec Keying Material in DNS 67 and Opportunistic Encryption using the Internet Key Exchange 68 released in December of 2005. Paul mentioned that Libreswan version 3.10 will re-introduce opportunistic encryption using a DNSSEC plugin which is now possible due to standardization of DNSSEC and with the features that permit storing arbitrary data in DNS servers, such as public keys for IPsec connections for the purpose of authenticating servers. Note that first RFC-s concerning DNSSEC were published already in 1999 69.

47: http://www.itu.int/rec/T-REC-X.509/en
48: http://tools.ietf.org/html/rfc4510
49: RFC 2560: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol (OCSP)
50: http://www.linux-ipv6.org/
51: https://www.hsr.ch/Advisors.1699.0.html ?&tx_icscrm_pi4%5Bcontent%5D=4758&tx_icscrm_pi4%5Bid_person%5D=525324
52: https://datatracker.ietf.org/wg/pkix/charter/
53: http://www.strongsec.com/freeswan/
54: https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt
55: https://download.openswan.org/openswan/old/openswan-1/openswan-1.0.0/README
56: http://code.credil.org/projects/credil-pub/wiki/Michael_Richardson
57: http://ca.linkedin.com/in/paulwouters
58: https://nohats.ca/wordpress/openswan/
59: https://nohats.ca/wordpress/blog/2014/02/16/development-of-libreswan-vs-openswan/
60: http://www.kame.net/project-overview.html
61: https://wiki.debian.org/IPsec
62: http://ipsec-tools.sourceforge.net/
63: http://freecode.com/projects/freeswan/releases
64: http://www.toad.com/gnu/netcrypt.html
65: http://www.freeswan.org/history.html
66: http://strongswan.org/docs/LinuxTag2007-strongSwan.pdf
67: RFC 4025: A Method for Storing IPsec Keying Material in DNS
68: RFC 4322: Opportunistic Encryption using the Internet Key Exchange (IKE)
69: http://tools.ietf.org/html/rfc2535

History of OpenSSH

In 1995, Tatu Ylönen, a researcher at Helsinki University of Technology observed that passwords can be retrieved from the network simply by monitoring traffic on the wire leading to compromise of several systems. To combat the situation he created FreeSSH which was intended to replace rsh, rlogin, rcp, Telnet, FTP and other legacy protocols that did not offer any protection against sniffing. FreeSSH was one among the first of such applications which featured encryption of remote shell sessions 71. FreeSSH 1.2.12 was the last version released under permissive license. Later FreeSSH put restrictions on commercial use and even prevented usage on DOS and Windows. In 1999, a Swedish computer scientist Björn Grönvall forked FreeSSH 1.2.12 and started tweaking it. That resulted in several releases over from 1999 to 2001. The releases are still available at KTH's FTP repository 70.

OpenBSD developers discovered OSSH two months before the release of OpenBSD 2.6 and immideately forked the project to accommodate changes required and called it OpenSSH. After OpenBSD 2.6 was released with OpenSSH various non-OpenBSD communities became interested and wanted to incorporate OpenSSH in their distributions. OpenSSH as it is known today is mainly used to gain access to command line of a remote computer. In addition to that it enables tunneling TCP connections in both ways. LTSP5 uses SSH's X11 forwarding capability to provide remote desktop access to terminals 72.

70: http://www.openssh.com/history.html
71: Pro OpenSSH by Michael Stahnke page 19 "What is SSH?"
72: http://www.ltsp.org/

Secure Shell standard

After OpenBSD 2.6 was released in 1999 Markus Friedl started working on SSH-2 protocol which later became standard endorsed by IETF. Most of the RFC-s were published mainly by SSH Communications Security Corporation founder Tatu Ylönen in collaboration with OpenSSH developers and others.

Documents released in 2006 consist of more than dozen RFC-s 73:

RFC 4250: The Secure Shell (SSH) Protocol Assigned Numbers
RFC 4251: The Secure Shell (SSH) Protocol Architecture
RFC 4252: The Secure Shell (SSH) Authentication Protocol
RFC 4253: The Secure Shell (SSH) Transport Layer Protocol
RFC 4254: The Secure Shell (SSH) Connection Protocol
RFC 4255: Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
RFC 4256: Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)
RFC 4335: The Secure Shell (SSH) Session Channel Break Extension
RFC 4344: The Secure Shell (SSH) Transport Layer Encryption Modes
RFC 4345: Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol
RFC 4419: Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol
RFC 4432: RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol
RFC 4462: Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol
RFC 4716: The Secure Shell (SSH) Public Key File Format

Several amendments have been made between 2007 and 2012:

RFC 4819: Secure Shell Public Key Subsystem
RFC 5647: AES Galois Counter Mode for the Secure Shell Transport Layer Protocol
RFC 5656: Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer
RFC 6187: X.509v3 Certificates for Secure Shell Authentication
RFC 6239: Suite B Cryptographic Suites for Secure Shell (SSH)
RFC 6594: Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records
RFC 6668: SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol (July 2012)

The Secure Shell standard covers mutual authentication using various algorithms, TCP connection forwarding and much more. According to modern requirements SSH-1 protocol is considered obsolete and insecure and SSH-2 should be used instead 74 75.

73: https://tools.ietf.org/wg/secsh/
74: http://www.openssh.com/specs.html
75: http://www.snailbook.com/faq/ssh-1-vs-2.auto.html

Secure Shell implementations

Many protocols have reference implementations for compatilibity testing puroposes. There is however no clear indication that OpenSSH is reference implementation for SSH-2 protocol. When querying folks at #openssh on Freenode IRC about the reference implementation, Aris Adamantiadis, one of the authors of libssh responded with following clarification:

21:09 < ar1s> lauri: I think there is no reference implementation
21:09 < ar1s> but SSH2 RFC are descriptive enough to make no mistakes

Having a well-defined standard has sprouted several implementations. Dropbear is SSH server and client distributed under a MIT-style license for POSIX-compatible operating systems written by Matt Johnton. It is mainly tailored towards embedded systems and it only implements SSH-2 protocol 76. Note that Dropbear server and client can be compiled to a ~100kB statically linked binary which is suitable for routers. On the other hand OpenSSH server and client binaries found on a regular desktop machine are around half megabyte each.

There are other implementations available in a form of library: libssh is a LGPL 2.1 licensed C library wich implements server and client code for SSH-2 and SSH-1 protocols. It can use OpenSSL or GCrypt for cryptographic operations 78. libssh2 is another BSD-style licensed C library which only implements SSH-2 client portion 79. Swiss Federal Institute of Technology from Zurich used to maintain Ganymed which was pure Java SSH-2 implementation released under BSD style license. Support and updates are now provided by Cleondris 77. Twisted Matrix Laboratories releases Twisted which is an event-driven networking engine written in Python and licensed under the open source MIT license 80. Conch is an addon package for Twisted which implements SSH-2 protocol in Python 81.

PuTTY is the most popular SSH client for Windows 82. It comes with PSCP and PSFTP for file transfer and Pageant which provides SSH agent functionality. US Department of Defense is using SmartCards to authenticate and PuTTY-CAC is piece of software which enables SmartCard authentication for PuTTY sessions 84. I tested and it also worked with Estonian ID-card aswell as they're both RSA hardware tokens standardized according to PKCS#11.

WinSCP is a Windows software focusing on file transfer using SSH protocol 85. Swish is a very similar project which enables mounting SSH file access using Windows Explorer Namespace Extension 86. There is also .NET based project win-sshfs which enables real mounting on Windows and allows network mapping drive 87.

Incorporating changes to a mature standard

In 2006 streamlocal project 88 led by William Ahern provided patches for OpenSSH 4.4 which enabled generic UNIX domain socket forwarding in addition to TCP sockets. I discovered the project in 2009 and I ported the streamlocal changeset to OpenSSH 4.9. Attmpts to bring the changes to any later versions failed as I was not an expert C programmer at that time. I had personal experience setting up modified OpenSSH which would allow LTSP5 server to gain access to the SmardCard readers attached to the terminals. When we did it back in 2010 it was pretty easy because streamlocal project had provided patches for OpenSSH that was used in Ubuntu 10.04 LTS.

In 2012 we did the same for Ubuntu 12.04, but it was significantly more complicated since streamlocal project had been dormant for some time and no newer releases were provided. I resorted to proving my own simplified patchset against which would enable needed functionality for OpenSSH 5.5 found in Ubuntu 12.04.

My related mailinglist post got few replies 89 and the reason in my opinion is simple - there is no mainstream need for such functionality and applying the changes in OpenSSH would require modification of the standard first as one of OpenSSH goals is to remain standard compliant 90 Changing the standard would require other implementations to add such functionality to remain compatible with the standard. The patches did not make it upstream mainly because it would have involved releasing update to the standard incorporating the changes needed by the patches.

As X11 forwarding is based on UNIX domain socket forwarding it is pretty silly that generic UNIX domain socket forwarding is not exposed. It would also close the potential security hole exposed by the X11 cookie management 91 as on the remote end a TCP socket is still opened. PulseAudio can forwarded to a remote machine via SSH aswell using TCP forwarding. To authenticate connections PulseAudio is using similar mechanism as X11 92. The generic UNIX domain socket forwarding would resolve those potential security holes of X11 and PulseAudio forwarding just by imposing UNIX filesystem permissions on the remote end.

88: http://www.25thandclement.com/~william/projects/streamlocal.html
89: http://www.ietf.org/mail-archive/web/ietf/current/msg64855.html
90: http://www.openbsd.org/openssh/features.html
91: https://www.debian-administration.org/article/494/ Getting_X11_forwarding_through_ssh_working_after_running_su
92: http://psung.blogspot.de/2011/09/network-audio-with-pulseaudio-made.html

Analysis

Current work lists nearly hundred standards that are used by mentioned software projects. I am reminding that this is still about getting chunk of bytes from point A to point B in a secure manner. The list of protocols and standards for building VPN-s is of course not complete and it's biased towards open-source solutions. Several protocols with particularily bad security record were omitted:

PPTP (Point-to-Point Tunneling Protocol) was formally specified in by a consortium formed by Microsoft, 3Com, Ascend Communications and others. 93
L2TP (Layer 2 Tunneling Protocol) originates from Cisco. 94 It does not provide encryption or confidentiality out of the box, instead it relies on IPsec. Such tandem is also known as L2TP/IPsec.
SSTP (Secure Sockets Tunneling Protocol) is very similar to OpenVPN as it encapsulates PPP tunnel within TLS channel. 95 SSTP also suffers what is known as TCP meltdown problem. 96

It is also clear that the the implementations duplicate the functionality, but the same applies for remaining standards.

Standards and API-s used by the projects

OpenVPN and Strongswan roughly implement the same category of functionality however the only common denominator are the cryptographic algorithms. The technical reasons are behind the fact that we have two conceptually different VPN approaches:

IPsec in which case the job is split between userspace application which exchanges keys between authenticated hosts and kernelspace modules which take care of encrypting outgoing packets and decrypt incoming packets.
SSL based VPN-s in which case most of the complexity sits in an userspace program which merely proxies packets from SSL/TLS tunnel to a virtual TUN/TAP interface.

OpenVPN was born out of necessity and practical needs whereas IPsec reflects the ideals of encryption on the Internet. Having significantly different codebase has it's implications - OpenVPN compiled against the vulnerable OpenSSL was affected by Heartbleed whereas StrongSwan was not.

There are different incentives involved. For instance if you're holding a patent on essential technology it might be a good idea to standardize the technology before the patent expires. That's exactly what RSA Security did with PKCS. Verisign, a RSA Security spin-off is making absurd amounts of profit even today. The military and intelligence agencies are of course reluctant to publish internally approved algorithms and methods to crack mainstream encryption algorithms. As mainstream algorithms have grown pretty strong the NSA's last line of defense has become weakening of implementations. Snowden revealed that NSA had paid $10 million US dollars to RSA Security to include weakened random number generator in RSA BSAFE 97, a FIPS 140-2 validated library sold by RSA Security. RSA categorically denies the allegation 98. The open-source community of course wants liberal parent and restriction free access to strongest possible algorithms. In a post-9/11 world it is much harder to advocate secure systems as it raises needless suspicions. Snowden revelations fortunately balance the situation.

In august of 2012 a standard for DNS-based authentication of named entities 100 was published which could potentially replace fundamentally broken certificate authority hierarchy that HTTPS currently relies on 101 102. This brings us back to DNSSEC and the idea of transparent encryption that were conceived as part of FreeS/WAN already in 1999. In addition the IPv4 address space is running out 99 and the need to upgrade to IPv6 becomes imminent. As IPsec is mandatory in IPv6 we will probably see shift from not-encrypted-by-default to John Gilmore's dream of ubiquitous transparent encryption between arbitrary endpoints in IPv6 network.

93: RFC 2637: Point-to-Point Tunneling Protocol (PPTP)
94: RFC 2661: Layer Two Tunneling Protocol (L2TP)
95: http://wiki.mikrotik.com/wiki/Manual:Interface/SSTP
96: http://sites.inka.de/bigred/devel/tcp-tcp.html
97: http://www.reuters.com/article/2013/12/20/us-usa-security-rsa-idUSBRE9BJ1C220131220
98: https://blogs.rsa.com/news-media/rsa-response/
99: http://www.computerworld.com/s/article/9207961/ Update_ICANN_assigns_its_last_IPv4_addresses
100: RFC 6698: The DNS-Based Authentication of Named Entities (DANE)
101: http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/
102: http://www.educatedguesswork.org/2009/01/can_we_replace_certificates_wi.html

Conclusion

It was fascinating to discover how Internet protocol was born for defense purposes, then adopted by academic/scientific communities and eventually found it's way to be exploited by businesses and individuals. Today's cryptography would not be possible without the extensive mathematical scientific work that was carried out over several decades by brilliant scientists.

It was interesting to dissect how community efforts and business interests align and cross and how the IETF standards eventually give common ground to operate on. It was also interesting to observe how US export restrictions have hindered development of IPsec standards as both FreeS/WAN and KAME initiatives came from outside US. FreeS/WAN demonstrated that people were worried about mass surveillance already in 1998. In 2013 Snowden only confirmed what privacy enthusiasts were suspecting.

As Paul Wouters said, RFC-s usually got drafted when there was piece of working code available, usually in a form of open-source project so RFC and implementations actually happened hand in hand. In such open setting the drama which might lead to forking of a particular codebase is easy to happen over trivial things.

OpenVPN successfully runs a custom protocol on top of other standardized protocols and enjoys wide adoption. IPsec is pretty well standardized but setting up for instance StrongSwan is pretty complex and sysadmins often choose in favor of OpenVPN, however in corporate environment IPsec seems to be popular because of support in proprietary software AND hardware.

Acknowledgements and references

I'd like to thank Paul Wouters (LetoTo), James Yonan, Aris Adamantiadis (ar1s), plaisthos, Noel Kuntze (Thermi) and probably many others who bothered to answer questions on Freenode IRC and forums. I'd also like to thank Peter Gutmann whose sarcastic articles made me laugh on several occasions.

OpenSSL OpenVPN OpenSSH IPsec FLOSS