This content is part of the Essential Guide: How to conduct a next-generation firewall evaluation

Secure Sockets Layer (SSL)

Contributor(s): Michael Cobb, Brendan Cusack, Peter Loshin

Secure Sockets Layer (SSL) is a computer networking protocol for securing connections between network application clients and servers over an insecure network, such as the internet. Due to numerous protocol and implementation flaws and vulnerabilities, SSL was deprecated for use on the internet by the Internet Engineering Task Force (IETF) in 2015 and has been replaced by the Transport Layer Security (TLS) protocol. While TLS and SSL are not interoperable, TLS is backwards-compatible with SSL 3.0.

SSL was originally specified in the 1990s as a proprietary protocol that allowed Netscape browser clients using the Hypertext Transfer Protocol (HTTP) to communicate securely with Netscape web servers. SSL eventually came to be used to secure authentication and encryption for communication at the network transport layer.

SSL uses a combination of public key and symmetric key encryption to secure a connection between two machines, typically a web or mail server and a client system, communicating over the internet or another TCP/IP network. SSL provides a mechanism for encrypting and authenticating data sent between processes running on a client and server.

SSL runs above the transport layer and the network layer, which are responsible for the transport of data between processes and the routing of network traffic over a network between client and server, respectively, and below application layer protocols such as HTTP and the Simple Mail Transport Protocol. The "sockets" part of the term refers to the sockets method of passing data between a client and a server program in a network or between processes in the same computer.

The TLS protocol evolved from SSL and has officially superseded it, although the terms SSL or SSL/TLS are still commonly used to refer to the protocol used to secure web/internet traffic. SSL/TLS is the most widely deployed security protocol used today and, according to Google, it is being used to secure more than 50% of the pages loaded by the Chrome browser. In addition to supporting the transmission of web pages, SSL has been implemented for applications including email, file transfer, instant messaging and voice over IP.

How it works

The SSL protocol includes two subprotocols: the record protocol and the "handshake" protocol.

The handshake protocol defines how a client and server establish an SSL connection, including the negotiation of which cryptographic systems each host is willing (or unwilling) to use for communication, as well as the exchange of cryptographic material, such as public keys and session keys for encryption or authentication of transmitted data.

The record protocol defines how communicating hosts exchange data using SSL, including specifications for how data is to be prepared for transmission and how it is to be verified or decrypted on receipt.

As part of the initial handshake process, a server presents its digital certificate to authenticate itself to the client. Server certificates follow the X.509 certificate format defined by the Public Key Cryptography Standards. The authentication process uses public key encryption to validate the digital certificate and to confirm that a server is, in fact, the server it claims to be.

Once the server has been authenticated, the client and server establish cipher settings and a shared key to encrypt the information they exchange during the remainder of the session. This provides data confidentiality and integrity. This whole process is invisible to the user. For example, if a webpage requires an SSL connection, the URL will change from HTTP to HTTPS, and a padlock icon will appear in the browser once the server has been authenticated.

The handshake also allows the client to authenticate itself to the server. In this case, after server authentication is complete, the client must present its certificate to the server to authenticate the client's identity before the encrypted SSL session can be established.

After the IETF officially took over the SSL protocol to standardize it through an open process, version 3.1 of SSL was released as TLS 1.0 (The name was changed to avoid any legal issues with Netscape). Many attacks against SSL have focused on SSL implementation issues, but the POODLE (Padding Oracle On Downgraded Legacy Encryption) vulnerability is a known flaw in the SSL 3.0 protocol itself, exploiting the way in which it ignores padding bytes when running in cipher block chaining mode. This flaw allows an attacker to decrypt sensitive information, such as authentication cookies. TLS 1.0 is not vulnerable to this attack because it specifies that all padding bytes must have the same value and must be verified.

Other key differences between SSL and TLS that make TLS a more secure and efficient protocol are message authentication, key material generation and the supported cipher suites with TLS supporting newer and more secure algorithms. TLS 1.2 is the most recent version, but publication of the next version is expected to be approved in 2017; that update is likely to be called either TLS 1.3 or TLS 2.0.

This was last updated in November 2016

Continue Reading About Secure Sockets Layer (SSL)

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

How many (SSL) are out there?
So please how can I subscribe to SSL?
Experts say the advancement of TLS is held up by maintaining backwards compatibly with SSL, so should enterprises be forced to upgrade legacy software and hardware to improve Internet security?
I do think if people were nudged a little harder to upgrade their systems we wouldn't see nearly as many problems with IT and security. The reality is, like most aspects of human behavior, people have their priorities and make their choices. I'm convinced we will never reach an ideal state of security - even in niche areas such as TLS/SSL - because of this.
"Forcing" anyone to do anything never works. Witness legislation attempting to accomplish such things normally just makes criminals out of otherwise law-abiding citizens. OTOH, incentives normally do work, so such a thing could be worked out. I tend to agree with Kevin that we'll never see an ideal state of security on the Internet, or anywhere else for that matter.

Read Security Corner for practical security advice.
How to identify which SSL version we are using, when we issue SFTP command?
It depends: in a browser like Chrome, clicking on the padlock security icon, and then "details" will give access to details about the connection security including the version of SSL/TLS and other cryptographic algorithms being used.

If the link cannot be accessed through a browser, you can use a network sniffer to capture the packets, and then look through protocol/algorithm information exchanged by the client/server.
May I know the cost of SSL?
Firewalls cannot inspect encrypted Internet traffic and that savvy hackers will use this to their advantage.
Traditional packet-filtering firewalls cannot inspect encrypted internet traffic, but so-called "middleboxes", which act as proxies for enterprise devices connecting to web servers, are used to decrypt, inspect and re-encrypt encrypted traffic.

Using this approach is not always a great solution, but it does give enterprises visibility into traffic that it would otherwise be blind to.

Check here for more about the debate on why HTTPS traffic interception gets a bad rap.


File Extensions and File Formats

Powered by: