Secure Sockets Layer

Secure Sockets Layer (SSL) is a common digital security measure used to enable the secure transmission of data between client and server. SSL is the predecessor to modern Transport Layer Security (TLS) which is frequently used throughout the internet. SSL and TLS are most frequently used in web servers and mail servers to protect user data such as login credentials or payment information.


SSL was developed for use in the first web browser developed by Netscape in 1995. The early releases of SSL by Netscape, however, were fraught with problems, causing versions 1.0 and 2.0 to be functionally useless.

Version 3.0, as imagined and developed by Paul Kocher, became the standard for SSL and served as the base architecture for the expansion of SSL, and later TLS.

TLS followed SSL Version 3.0 and was functionally similar but the two systems were not compatible with one another except through a downgrade in security when translating from TLS to SSL. TSL 1.0 provided a more robust level of security than SSL 3.0 and rapidly took over SSL as the industry standard for website and client-server security.

TLS 1.0 was followed by TLS 1.1 and TLS 1.2, which both added additional security features, such as TLS Extensions and protection from cipher block chaining attacks. These updates also removed the backward compatibility of TLS to SSL.


Browser SSL
Image Unavailable

SSL and TLS are key features in many common internet tasks such as:

• Online monetary transactions on websites such as Google Wallet or Bitcoin

• Securing login credentials

• Providing secure file transfer over FTP and HTTPS

• Using VPN software to connect to the internet

• Securing webmail servers

One key feature of SSL and TLS is the ease of use for the end user. The most frequently encountered example of this is the green padlock symbol or green address bar in web browsers that certify that a website is secure.

SSL Certificates

SSL Certificates operate on a public key system in which the client and the server exchange both a private and a public key in order to access information.

In order to receive a certificate, the server administrator creates a Certificate Signing Request (CSR) on their server. This generates a CSR data file to be sent to a Certificate Authority as well as the private key that will be used for SSL encryption later on. Based upon the data in the CSR, the Certificate Authority generates a public key to match the server’s private key. It is important to note that the Certificate Authority never receives the actual private key.

After installing the SSL Certificate, server administrators might also install intermediate certificates in order to increase the integrity of the original SSL Certificate.

The SSL Certificate is then recognized by the end user’s browser based upon a set list of trusted organizations. This trust is established when the Certificate Authority confirms that the organization is legitimate and trustworthy.

How SSL Works

How SSL Works
Image Unavailable

1. User’s browser connects to a website secured with SSL (https).

2. Browser requests that the server identify itself.

3. Server sends a copy of its SSL Certificate, including the server’s public key.

4. Browser checks the SSL Certificate against a list of trusted Certificate Authorities.

5. If the browser trusts the certificate, it creates, encrypts, and sends back a symmetric session key using the server’s public key.

6. Server decrypts the symmetric session key using its private key and replies with an encrypted message with the session key to start the encrypted transmission of data.

7. Server and Browser now encrypt all transmitted data with the session key.

Potential Weaknesses

The primary vulnerability of SSL and TLS is that the algorithms upon which they are based become weaker over time. Neither system is completely secure from attack, so if the algorithms are not frequently updated, they will become increasingly vulnerable. Recently, the potential weakness of SSL was exhibited by the Heartbleed bug.


Image Unavailable

The Heartbleed bug is an exploitation of a vulnerability in the "Heartbeat" extension of OpenSSL, a popular opensource toolkit for SSL and TLS.

The heartbeat extension is intended to provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path MTU (PMTU) discovery for DTLS.1 This allows the client-server model to maintain a secure connection for extended periods of time without having to re-form the secure connection constantly. This is achieved by the client sending a message to the server requesting that it repeat it's message back to it. For example, the client could send out a message such as "send back the five letter word House" and the server would reply "House" in order to show that the connection is still alive.

The Heartbleed bug exploited the lack of a bounds check in the heartbeat extension, allowing malicious clients to send a heartbeat request that did not match the bounds of the reply. Using the above example, a malicious user could send the heartbeat message "send back the 2000 letter word House." Since "House" is only five letters and the server has been requested to return 2000, the server compensates by replying "House" followed by 1,995 characters that are stored in its recent memory. If the server had credit card information or social security numbers in its recent memory, these would be included in the heartbeat response.