SSL and Beyond, Part 1: History, and Development

Online communications and e-commerce are fast replacing more traditional methods. So there’s a real need for data to be moved around through secure channels. That’s where protocols like the Secure Sockets Layer or SSL have a part to play.

This series will consider the evolution of SSL, its current deployment, and options for the future. We’ll start by looking at its origins and development.

Security? What’s The Panic, Anyway?

While legislation like the U.S. government’s Health Insurance Portability and Accountability Act (HIPAA) can provide a level of protection to sensitive data and give prescriptions for the way it should be handled, it’s tough to legislate for data in transit – or to protect the computer systems on which it’s kept.

Eavesdropping, impersonation, and wiretapping are just some of the methods used by unscrupulous operators to gain access to information in transit. To reduce this risk, one approach is to scramble or encrypt data as it moves between its source and its recipients.

On today’s internet, the SSL family is the preferred communications protocol for secure transactions.

A Protocol?

In computing terms, a protocol is simply a set of rules determining the format and transmission of data – though the rules themselves may not be simple.

An API or application programming interface known as SNP (Secure Network Programming) was developed in 1993 to address the lack of strong security measures in existing network applications. This API employed a secure transport layer that was similar to Berkeley sockets.

There’s SSL…

The Secure Sockets Layer protocol was intended to provide a safe platform-and-operating-system-independent path for encrypted data that passes between clients and servers.

The project was initiated by Netscape in 1994, at a time when the company was looking to address growing concerns over unsecured communications on the internet. Specifically, the firm was looking to ensure secure links between its own Netscape Navigator browser, and the web servers it would connect to.

SSL was designed to use powerful encryption algorithms that would also meet the Advanced Encryption Standard (AES), which had emerged as the yardstick for encrypted communications at that time. SSL can secure the transmission of any data that moves via the Transfer Control Protocol (TCP).

As well as encryption, SSL ensures secure communications by the use of authenticated digital certificates. A digital certificate is like a set of official credentials; it establishes the holder’s identity and ensures that they are who they claim to be.

Under SSL, a user establishes that the website they are about to exchange data with is on a trusted server once its certificate is verified. Verification of identity helps users to avoid fraudulent websites.

Its Various Versions…

SSL version 1.0 never saw the light of public release.

February of 1995 saw the arrival of SSL 2.0. As with any software evolution process, this release contained a number of kinks and some security flaws.

In 1996, SSL 3.0 was released. This version improved on the previous ones by adding support for the authentication of digital certificates, and by beefing up its encryption algorithms with SHA-1 based ciphers. It set the standard for internet communications security for several years.

Then There’s TLS…

SSL 3.0 had some weaknesses in the process used to derive its encryption keys, which created security vulnerabilities.

The Internet Engineering Task Force (IETF) took over official ownership of the SSL standard, and set up a process to eliminate the weaknesses of previous versions.

An upgrade was issued in January 1999, along with a new designation: Transport Layer Security (or TLS). Like SSL, it used symmetric cryptography to scramble elements of network communication above the Transport Layer, and ensured the reliability of messages via authentication codes using public and private keys.

TLS 1.0 (sometimes designated as SSL 3.1), while similar in many respects to SSL 3.0, was only backwards-compatible with it. In certain circumstances, a TLS 1.0 connection could be downgraded to SSL 3.0.

In April 2006, TLS 1.1 arrived with greater protection from Cipher Block Chaining (CBC) attacks, alterations in the way padding errors were handled, and other slight modifications.

TLS 1.2 emerged in August 2008. It was based on the TLS 1.1 model, but with a major overhaul of the encryption algorithms and digital signatures process, and with extended support for authenticated encryption ciphers.

Securing Connections

Secure Sockets Layer combines three aspects, to ensure the security of connections:

• Encryption of data to ensure the privacy of connections

• Authentication of identity through digital certificates

• Checking the integrity of messages to ensure that a secure connection is maintained throughout

Laying the Groundwork

For a user or client system/application wishing to use SSL to connect securely to a web-based system, the web server must have a valid digital certificate. The server administrator can get one from a recognized Certification Authority (or CA). A certificate allows the web server to identify itself to the client so that communication can proceed.

Note that it isn’t essential for the client to have a digital certificate on his/her machine to connect to a secure server. That’s why it’s possible to check your web-based email account from different machines without having to port a certificate around.

Most modern web browsers inherently support the SSL protocol, and this eliminates the need to configure SSL connections on the client’s side of the transaction. Web servers do have to be configured, typically to allow several sites to store their digital certificates on the system. Administrators should be able to identify and verify each application hosted on the server. Users should be able to readily differentiate between each application.

The SSL protocol has been known to slow down connections, as encryption keys and other data are exchanged at the start of a communications session. So network administrators are also advised to consider installing SSL accelerators (dedicated PCI cards) to their servers.

Encryption of Data: Public and Symmetric Keys

In private/public key encryption, the private key is kept secret, while the public one can be distributed to all intended recipients of a communication. Key pairs are built up from prime numbers. The longer a key is, the more difficult it would be for a (malicious) user without access to the key pair to decrypt an encoded message.

If you’re a key holder, anyone in the network can send you an encrypted message, which you’ll be able to decrypt. Using a private key, you can confirm that an encrypted message originated from you – one that can only be decrypted by the associated public key. To get details of your recipient’s public key, you need him/her to send you a signed message (which won’t be confidential), containing their public key and a valid digital certificate.

Data encrypted using a combination of a public and private key is deemed to be asymmetric. Information can be scrambled by one key, but it can only be decoded by the other key pair. The functions of the keys can be switched, with one key pair decrypting what the other key has encrypted.

Practical difficulties can arise. The other key pair is needed to perform decryption – and you can’t encrypt and decrypt with the same key.

Symmetric keys are used in processes where the same key is used to decrypt and encrypt data. The algorithms are much faster than for private/public keys, but are inherently insecure. It’s essential to transmit the key to your recipient by putting it inside a message that has been scrambled asymmetrically.

For each communication, the symmetric key must be selected randomly. So, if one message is intercepted, the next one will contain a different key.

Digital Certificates, and Signatures

To set up an SSL transaction, an application must have a digital certificate assigned to it by a Certification Authority. The certificate will contain a unique public encryption key, and be sealed by a protective hash – which is a random number generated by a hash function from a message.

Private keys are not contained within a certificate to preserve their security. With the public key, a certificate can send an encrypted transmission to its owner or verify a message signed by its author.

The digital certificates used in SSL confirm to web browsers the identity of the website they’re visiting. If a user wishes to transmit sensitive or confidential data to a web server, their browser will first assess the validity of the site’s certificate, before attempting to establish a secure connection. The encryption required to do this will itself refer to the digital certificate to confirm the authenticity of the recipient.

Before being issued with a certificate, its owner must first provide basic information about themselves, such as their name, email address, and web address. The certificate will come with conditions of use and a period of validity, and specify a Distinguished Name, which is made up of the certificate owner’s email or website address, together with the certificate ID of the person who has certified or signed all of this information.

A user’s web browser or application will have typically pre-loaded an index of root certificates from trusted Certification Authorities (CAs). The CA itself should retain a list of all certificates signed under its authority, and those which have been revoked.

Signed certificates can’t be modified, so a certificate with a signature on it is secure, and vice versa. It’s possible to sign a certificate using itself; it’s known as self-signed. This is the case with all root CA certificates.

Maintaining Message Integrity: Handshakes and Such

The Secure Sockets Layer protocol incorporates four layers:

1. The Record Layer Protocol

This is a formatting stage prior to transmission. A header is generated for each message, along with a hash at the end, which derives from a specific Message Authentication Code (MAC). The SSL protocol dictates that any message following the header cannot exceed 16,384 bytes in length.

2. The ChangeCipherSpec Protocol

This layer of the operation consists of a single message, signaling the start of secure communications between client and server. It employs the same format as the Record Layer, but the ChangeCipherSpec message simply uses the value of ‘1’ to indicate a change in the communications protocol.

3. The Alert Protocol

Error messages, warnings, or problems with the connection between client and server are covered by the Alert Protocol. It’s defined by a Severity Level, which takes the value of ‘1’ for a caution or warning. In this case, SSL sends a suggestion to both parties that they should discontinue this session and use a fresh handshake to reconnect. A Severity Level of ‘2’ is fatal, and requires both parties to immediately discontinue the session.

To further clarify matters, an Alert Description number is generated at each alert to indicate the specific problem that caused the alert message to be sent. SSL has a scale of 12 numbers and TLS has 23, with each representing different conditions and levels of severity.

4. The Handshake Protocol

The Handshake in an SSL transaction is the passing of messages between client and server to initiate a secure connection.

A ClientHello message sets out the options which the client (e.g. your web browser) is prepared to use to communicate with a web server. For example, this might include the version of SSL or TLS to be used, and CompressionMethods employed by the client. At this stage, a 32-byte RandomNumber is generated to help the client set up encryption.

In response, the server selects options based on the ClientHello conditions and sends back a ServerHello message.

A ServerKeyExchange occurs next, during which information is exchanged between client and server to set out how data is to be encrypted. With no encryption algorithm having been agreed upon at this stage, this information is sent as is. But the server’s public key is used to encrypt a session key, which will later be used to encrypt the data to be transmitted. Digital certificates are examined at this stage to make sure that everyone is who they claim to be.

A ServerHelloDone message concludes this stage.

ClientKeyExchange is next. This message holds information about the key, which both parties will use to communicate.

The transition from insecure to secure data transmission is then signaled by two ChangeCipherSpec messages, as client and server switch to the agreed secure state.

Two messages confirm that the SSL Handshake is Finished. Key Information, the content of all previous handshake messages passing between the two systems, and the generation of a unique value to identify the sender as a client or server must all be verified before the handshake concludes.

What The User Sees:

It’s at this point that the familiar padlock symbol appears in the user’s web browser to indicate a secure communication. And the ‘http’ prefix of the web address changes to ‘https’.

Signing Off

When all the Handshake information has been verified, secure communications can proceed. A Message Authentication algorithm is attached to the end of each message. It creates a digital summary or hash of the data contained in the message, so that any change in that information will be reflected by a corresponding change in the hash.

To sign a message, you first generate its hash, and then use your private key to encrypt the summary. You must then add the encrypted hash and your own digital certificate to the message. Your message hash must be recreated then decrypted by the recipient, who will use your public key (as contained in your digital certificate).

The recipient should check that both hashes match, and authenticate the validity of your certificate.

A secure method for signatures is to encapsulate a text message inside with delimiters.

Signing off is what we’re doing now. In the next installment of this series, we’ll look at how SSL is deployed across various platforms and operating environments. Hope you’ll be here for that.