General Info

Introduction

A basic overview of SSL including what it is, why it exists, its components, its uses, and information about the SSL handshake.

What is SSL?

SSL, and its successor Transport Layer Security (TLS), is the de facto standard for secure web transactions. SSL provides a framework for security methods to authenticate (verify the identity of) servers and clients, verify the contents of messages, and encrypt messages.

Why SSL Exists

TCP/IP, the protocol for getting data from point A to point B on the Internet, was designed during the Cold War by the US Department of Defense (DOD). As such, the DOD made TCP/IP very robust. TCP/IP can use any number of different routes to get data from one point to another, rather that using a set route all the time. The data is broken down into a series of packets, which can arrive out of order with no ill effects. Packets that do not arrive are also re-transmitted.

All of this allows TCP/IP to automatically recover from any disaster that may occur on the network. If troop deployment information is being transmitted from one node on the west coast to another node on the east coast through a third node in the mid-west and the city the third node is in is hit by a nuclear warhead, the data will automatically be re-routed through a fourth city, and any packets that happened to be lost because they were physically located in the third city when it was hit will be re-transmitted.

This robust networking protocol does create some security issues. Because the data could be routed through any node at any time, the data is not secure. If a node the data is being routed through is compromised a hacker would have access to any data flowing through that node. This would allow the hacker to intercept sensitive data, falsify the data as it flows through his node, transmit forged messages to either participant that appear like they came from the other participant, or pretend to be a different node so that another party communicates with him instead of the node they intended to communicate with.

This is where SSL comes in. By providing a framework to verify the identity of the other party, an intermediary node cannot pretend to be another node. Methods for verifying the contents of a message by including a hash of the message — a sort of summary — ensures that messages are not being tampered with. Finally, by providing ways to encrypt data in transit, hackers cannot access sensitive information.

SSL Components

The SSL protocol consists of two sub-protocols. One is the SSL record protocol, which dictates how messages are passed between two participants in the SSL session, and is used from the time one of the participants requests an SSL session until the session ends. The other is the SSL handshake protocol, which governs the initial process of establishing the connection. During the handshaking session the two participants decide which cipher to use for encrypting and decrypting data, which hash to use for message verification, and verify each other's identity. SSL is designed as a modular framework, so that components can be quickly and easily added and disabled.

Hashes are mathematically derived from messages, and concisely represents the longer message. Cryptographic hashes need to be easy to compute, so that the recipient of a message can quickly generate a hash and compare it to the hash transmitted with the message to verify that the message wasn't tampered with. The two most common hashes in use today are MD5 and SHA-1. MD5 generates 128-bit hashes, and special cases where two messages can have the same hash have been found, although the odds that a hacker could use that to his advantage are extremely small. SHA-1 generates 160-bit hashes and has no known weaknesses.

Another component of SSL are key exchange algorithms, which generate the encryption keys that will be used during the SSL session. RSA (Rivest, Shamir, Adleman), KEA (Key Exchange Algorithm), DH (Diffie-Hellman), and KRB5 (Kerberos 5) are the most commonly used. RSA has been used in all versions of SSL. KEA was used in the government-only FORTEZZA system and wasn't supported until SSL 3.0. DH and KRB5 are both relatively recent additions — Kerberos is a long-standing, network authentication protocol created at MIT.

Ciphers are the methods used to encrypt and decrypt messages. All of the ciphers are designed to require possession of at least one key to decrypt messages, and to make the only way to determine a key a process of guess-and-check called "brute force". The length (number of digits) of a key comes into play when someone is trying to brute force the key, as the longer the key the more possible keys there are that the hacker has to try. The idea is to use keys that are long enough that it's infeasible to break them in a reasonable amount of time.

Acceptable key length for any given use is increasing all the time, as computers get faster all the time, thereby making it so they can brute force a particular key in less time. For example, until 1999 the longest key that could be used in a cipher suite that could be legally exported out of the US was 40-bits. This created a potential pool of 240, or 1.1×1012 (1 trillion) keys, which lawmakers felt couldn't be cracked in a feasible time by the majority of hackers, but could be broken by law enforcement, who have access to better (more expensive) computing equipment. However, by 1997 computers had gotten fast enough that studies showed that the average PC of the day could brute force a 40-bit key within a week. In 1999, the limit was raised to 128-bit, which offers 3.1×1026 (300 septillion) times as many possible keys as a 40-bit key. (Meaning that it would take a given computer 300 septillion times as long to crack.)

Probably the most well-known ciphers are: Advanced Encryption Standard (AES), Data Encryption Standard (DES), International Data Encryption Algorithm (IDEA), RC2, RC4, SKIPJACK, and Triple-DES (3DES), although many more are available in SSL. DES, which uses 56-bit keys, was the official cipher standard of the US government from 1976 until 2001, when it was replaced by AES. Because DES uses such a short key it is easily breakable today with modest computing equipment, which is the main reason it was replaced. 3DES applies DES three times, using different keys, similar to having a 168-bit key. To find a successor to DES, a contest was held and the winning algorithm became AES. AES can use 128, 192, or 256-bit keys, and no known successful attacks exist. IDEA is used in the Pretty Good Privacy (PGP) encryption software, and uses 128-bit keys. RC2 uses a variable size key and is vulnerable to some attacks. RC4 is the only stream cipher — where data is encrypted one bit at a time, rather than in blocks — on this list, uses variable key lengths up to 256-bit, and the first few bytes of encrypted data are non-random, causing most modern implementations to discard them. SKIPJACK was a classified cipher used by the government with FORTEZZA that used an 80-bit key. Within a day of being declassified, an attack with a 50% success rate was found, this attack was refined to 97% in a few more months.

Certificates are used for identity verification. They contain the host's public key — which allows other parties to send the host encrypted messages that only the host can decrypt — a serial number, dates which define a validity period, the Distinguishing Name (DN) of the certificate (e.g. www.utah.edu), and the DN and digital signature of the Certificate Authority (CA) that issued the certificate.

SSL Handshake

The SSL handshake begins by the client contacting the server and transmitting the client's SSL version, cipher settings, some randomly generated data, any other information that might be needed, and a request for server authentication. The SSL version and cipher settings determine, amongst other things, which hashes, key exchange algorithms, and ciphers can be used. Each version of SSL has access to a specific set of ciphers, and the operator can further disable some of those ciphers. (The insecure ones, for example.)

The server responds with its SSL version, cipher settings, another piece of random data, any other information needed, and its certificate. The server, depending on the service requested and its settings, may optionally request client authentication.

The client then authenticates the server. The first thing it does is check if the current date is within the validity period in the certificate. Then, the client will check if the CA that issued the certificate is trusted. Every client maintains a list of trusted CAs, which it checks first. If the issuing CA is not in the list, but is subordinate to another CA, the client will check the superior CA. If that CA is also not in the list, but is subordinate to another CA, the client will check that CA, and so on until it either fails by running out of CAs or succeeds by finding one that it trusts. If the issuing CA is determined to be trustworthy, the client will use its public key to validate its digital signature. Finally, the client checks if the server's DN matches the one listed in the certificate.

If the server is successfully authenticated the client will continue. If not, the client will warn the operator that the authenticated, encrypted SSL session cannot be established. How this is handled depends on the application being used: some may allow the operator to elect to continue with the insecure session.

The client then generates a premaster secret. The first two bytes of the premaster secret contain the SSL version being used, the remaining forty-six are randomly generated. The client encrypts this using the server's public key — remember, only someone with the server's private key can decrypt something encrypted with its public key — and sends it to the server. If client authentication was requested, the client will also generate a hash all of the SSL message generated so far, encrypt them with the client's private key, and send that signature along with its certificate to the server with the premaster secret.

If the server requested client authentication, it will use the public key in the client's certificate to decrypt the client's signature. Then it will check if the current date is within the certificate's validity period. The issuing CA of the client's certificate is then checked, using the same process of checking superior CAs if the issuing CA isn't in the server's list of trusted CAs and is subordinate to another CA if needed. If the issuing CA checks out, the server will use the CA's public key to validate its signature. Another optional step is that the server can check if the user's certificate is listed in the corresponding LDAP entry. Finally, the server will check its Access Control Lists (ACLs) to see if the client is authorized to access the requested service.

If any of these tests fail, the server will terminate the SSL session. If the client is authenticated, or if the server did not request client authentication and skipped this process, the handshake will continue as below.

The server will then decrypt the premaster secret. Then, starting from the same premaster secret and using the same steps, the client and server will generate a master secret. The master secret will be the same for both, but will never be transmitted — meaning that no third-party can intercept it.

Using the master secret and again following the same steps, the client and server will then generate the session keys that will be used. Since the same key will be used to encrypt and decrypt messages, rather than one key used to encrypt and a second to decrypt as had been used so far, the actual SSL session will use symmetric cryptography. (As opposed to public key cryptography used during the handshake.) The advantage of symmetric key cryptography is that it is faster than public key. The disadvantage is that it is less secure. However, since public key cryptography has been used up to this point, neither the key nor the data used to generate it is never transmitted, and the data it is descended from includes a lot of random data that was then encrypted using public key cryptography the session will be reasonably secure.

The client transmits a message that all future messages will be encrypted with the session keys. The client then transmits its first message encrypted with the session keys, stating that the client's part of the handshake is done. The server also transmits a message that all future messages will be encrypted with the session keys, and a messages stating that its part of the process is done. The SSL session has begun.

Uses of SSL

SSL is meant to be a general-purpose framework, which makes it useful for almost any network activity that requires security. The most common uses of SSL include online banking, online shopping, secure email, and secure news. The "https://" prefix on a web address indicates that SSL is used by that server.