For Geeks: Technical Details and More History
Those who are technically inclined may be interested in diving further into the details of how SSLs work and how SSL became part of the Apache Web Server.
Initiating a Session
Initiating a session is as simple as loading a web page that begins with the
Note the difference between
https://. That extra ‘s’ is what makes the connection secure.
When you press enter, your web browser initiates a connection to the website. It will send information that is not confidential to do this. When the server replies, it sends the browser its certificate and a public key.
Your web browser then validates the certificate and returns a secret key to confirm that the connection is secure. Once that happens, all data is protected by a virtually unbreakable encryption algorithm.
How SSL Became Part of the Apache Web Server
For a connection to be encrypted, both sides of the connection must be able to communicate. So in the case of SSL, both the user’s browser and the web server must understand the protocol.
This means that both browser manufacturers and web server makers had to add SSL to their applications.
The Earliest Versions of Apache
By far, the most used web server is Apache. Coincidentally, both Apache and SSL were released the same year: 1995. For obvious reasons, the first version of Apache didn’t include SSL because:
- There was no time to include it
- Almost no browsers supported it
- And the web wasn’t the commercial marketplace it is today
Adding SSL to Apache: Apache-SSL
But the potential of adding SSL to Apache was immediately apparent. So Ben Laurie took Eric A Young’s open-source SSLeay (eay for Young’s initials), which he first released in 1995, and combined it with Apache, which is also open-source. The result was SSL-Apache.
(Eventually, Apache-SSL switched from SSLeay to OpenSSL. This is because the SSLeay project was ended. OpenSSL was forked from the last version of SSLeay.)
So very quickly, people could have their own SSL-enabled server. But there was a problem. Every time SSLeay/OpenSSL or Apache was updated, Apache-SSL had to be updated. In addition to having to fix its own bugs, this required a lot of work. In other words, SSL-Apache was a maintenance nightmare.
Apache Modules to the Rescue!
Apache has a module system, which allows programmers to create compiled code that adds functionality to the base system. For example, mod_cgi adds a CGI system to the server.
So, in 1998, Ralf S. Engelschall decided to port Apache-SSL (1.17) into a module for Apache 1.2 that he called mod_ssl. This improved Apache-SSL in a big way. So when a new version of Apache came out, mod_ssl didn’t need to be changed.
However, because of conflicts with the Apache-SSL development cycle, for version 1.3 of Apache, mod_ssl v2 became completely independent of the older system. It was written from scratch and effectively became part of Apache.
In addition to Apache changes not affecting mod_ssl, mod_ssl could make changes without having to mess with the base Apache code.
This meant that changes to SSL or improvements to the module could easily be made.
How Does mod_ssl add SSL Encryption to Apache?
The mod_ssl does not provide SSL encryption to Apache itself. Instead, it provides an interface so that Apache can use OpenSSL. OpenSSL is an open-source implementation of the SSL/TLS protocols.
OpenSSL is the most popular encryption software library. It is used in most open-source software that wants to add encrypted communication to it.
OpenSSL is a great product. But it isn’t perfect and not everyone likes it. As a result, over the past several years, a number of OpenSSL forks have appeared.
In 2009, Marco Peereboom released Agglomerated SSL. It doesn’t change the encryption code itself. Instead, it simplifies the interface.
This makes Agglomerated SSL easier to include in different programs. It is used, for example, to allow VLC to be able to play Blu-ray discs.
Five years later, the Heartbleed bug appeared in version 1.0.1 of OpenSSL. It was so bad that it could allow hackers to determine a user’s private key. A number of quick fixes solved the problems of the Heartbleed bug. But it wasn’t until OpenSSL version 1.0.1g that Heartbleed was completely defeated.
The bug was not disclosed publicly for two years, in 2014. This caused the creation of LibreSSL by members of the OpenBSD project.
Within days of LibreSSL’s release, problems with it were reported, but it is not clear just how important these problems were.
Regardless of any early problems, LibreSSL has gone on to be developed. It is not only the default TLS for FreeBSD, but also for a number of Linux distributions. New releases are available on average every four months or so. Overall, it has had fewer problems than OpenSSL.
Just after LibreSSL came out, Google released BoringSSL. But it isn’t meant for general use the way OpenSSL and the two other forks are. Google is working with OpenSSL and BoringSSL to create an SSL library for use with its own projects.
Google recommends against other developers using BoringSSL. But it is likely to be running in many applications people are using.
Mod_ssl Becomes an Official Part of Apache
Because of some changes in US law about exporting cryptography, mod_ssl became an official part of Apache 2. The Apache Software Foundation now maintains it.
Given that server-side SSL involved two distinct applications and numerous teams and individuals, it’s helpful to see the timeline that brought us to our current state.
||Version 1.0 created (never released)
||First public release (V 2.0)
||First Public release (V 0.6.2)
||First Public release
||First Public release
||Forked from SSLeay, first public release (V 0.9.1)
||Ported from Apache-SSL V 1.17 but not released
||First public release (V 2.0.0)
||Became an official part of Apache
||First version of this OpenSSL fork
||Heartbleed bug introduced
||Fork of OpenSSL V 1.0.1g introduced
||Google’s fork of OpenSSL for internal use
||Current stable version V 2.4.29
||Current stable version V 1.1.0g