An Overview of SSL (version 2)

Adam Shostack, May 1995

SSL version 3 is in the draft stage. I believe that SSL version 2 is in Netscape Nevigator version 2.

A. Introduction to, and history of, SSL

SSL, Secure Sockets Layer, is a protocol designed and implemented by Netscape Communications. Netscape claims it is designed to work, as the name implies, at the socket layer, to protect any higher level protocol built on sockets, such as telnet, ftp, or HTTP. As such, it is ignorant of the details of higher level protocols, and what is being transported. A free reference version of SSL, SSLRef, is available from Netscape. Many of the functions provided by SSL are part of the newly defined IPv6.

SSL provides for encryption of a session, authentication of a server, and optionally a client, and message authentication. The SSL Handshake Protocol and the application protocol both operate on top of the SSL Record Protocol, a simple means of encapsulating authentication information. SSL-Record Layer works on TCP or some other reliable transport mechanism. Session establishment takes from 5 to 8 messages, depending on options used. SSL relies on the existence of a key certification mechanism for the authentication of a server. SSL does not provide for renegotiation of keys within a session. (This is not a problem in HTTP, but might be with other protocols.) A multitude of ciphers and secure hashes are supported, including some explicitly weakened to comply with export restrictions.

B. The SSL protocols

1. SSL Record Protocol
All SSL protocol messages move in records of up to 32,767 bytes. Each message has a header of either 2 or 3 bytes. The headers include a security escape function, a flag to indicate the existence of padding, and the length of the message (and possibly the padding.) A two byte header has no padding, a three byte header includes some padding.

	The meaning of bits is as follows:

 1 2 3 4 5 6 7 8                    
|# S Length      |  Length         | Padding length |

# is the number of bytes in the header
	0 indicates a 3 byte header, max length 32,767 bytes.
	1 indicates a 2 byte header, max length 16,383 bytes S
indicates the presence of a security escape, although none are
currently implemented. (Several suggestions for security
escapes are in the weaknesses section.)
There is no version information within the SSL record header, although it is available in the handshake.

Within a record, there are three components: MAC-DATA, Actual-data, and Padding-data. MAC is the Message Authentication Code, Actual-data is the actual data being sent, and Padding-data is padding.

The MAC-DATA is a hash of a key, the data, padding, and a sequence number. The hash is chosen based on the cipher-choice. The key used is the (sender)-write-key, which is the same key as the (receiver)-read-key. When cipher-choice is not defined, there is no mac-data or padding-data.

Padding is used to ensure that the data is a multiple of the block size when a block cipher is used. Padding data is always discarded after the MAC has been calculated.

Sequence numbers are unsigned 32 bit integers incremented with each message sent. Sequence numbers wrap to zero after 0xFFFFFFFF. Each dialog direction has its own sequence number.

Failure to authenticate, decrypt, or otherwise get correct answers in a crytpographic operation result in I/O errors, and a close of connection.

2. SSL Handshake Protocol
A handshake occurs when a machine attempts to use a SSL connection. There are three basic types of handshaking. The first is when no session exists "recently". Recently is not explicitly defined, but suggested to be under 100 seconds (SSL, C.8). The second is when the a set of session identifiers still exists, the third is when client authentication is desired.

For the initial connection, when a client wishes to establish a secure connection, it sends a CLIENT-HELLO message, including a challenge, along with information on the cryptographic systems it is willing or able to support. The server responds with a SERVER-HELLO message, which is connection id, its key certificate, and information about the cryptosystems it supports. The client is responsible for choosing a cryptosystem it shares with the server.

The client then verifies the server's public key, and responds with a CLIENT-MASTER-KEY message, which is a randomly generated master key, encrypted or partially encrypted with the servers public key. The client then sends a CLIENT-FINISHED message. This includes the connection-id, encrypted with the client-write-key. (All these keys are explained separately, in the next section.) The server then sends a SERVER-VERIFY, verifying its identity by responding with the challenge, encrypted with the server write key. The server got its server-write-key sent to it by the client, encrypted with the server's public key. The server thus must have the appropriate private key to decrypt the CLIENT-MASTER-KEY message, thus obtaining the master-key, from which it can produce the server-write-key.

When a session identifier is found by the client, a slightly different initialization takes place. It is initially distinguishable by the CLIENT-HELLO message including a session-id. The SERVER-HELLO response includes a set "session_id_hit" bit if the session-id is found. The client then sends an encrypted connection-id for this session in the CLIENT-FINISH message. The server responds with a SERVER-VERIFY and a SERVER-FINISH message, which are close to identical to those used in the "No session identifier case." The only difference is that the SERVER-FINISH message contains a session-id instead of new-session-id.

If client authentication is in use, then the server must at some point, send a REQUEST-CERTIFICATE message, which contains a challenge (called challenge') and the means of authentication desired. The client responds with a CLIENT-CERTIFICATE message, which includes the client certificate's type, the certificate itself, and a bunch of response data. The server then sends a SERVER-FINISH message.

To summarize those messages, they are:

 2.2.1 Assuming no session-identifier

          client-hello		C -> S: challenge, cipher_specs
          server-hello		S -> C: connection-id,server_certificate,cipher_specs
          client-master-key  	C -> S: {master_key} server_public_key
          client-finish		C -> S: {connection-id} client_write_key
          server-verify		S -> C: {challenge} server_write_key
          server-finish		S -> C: {new_session_id} server_write_key

2.2.2 Assuming a session-identifier was found by both client & server

          client-hello		C -> S: challenge, session_id, cipher_specs
          server-hello		S -> C: connection-id, session_id_hit
          client-finish		C -> S: {connection-id}client_write_key
          server-verify 	S -> C: {challenge}server_write_key
          server-finish		S -> C: {session_id}server_write_key

2.2.3 Assuming a session-identifier was used and client
          authentication is used

          client-hello		C -> S: challenge, session_id, cipher_specs
          server-hello		S -> C: connection-id, session_id_hit
          client-finish		C -> S: {connection-id}client_write_key
          server-verify 		S -> C: {challenge}server_write_key
          request-certificate	S -> C: {auth_type,challenge'}server_write_key
          client-certificate	C -> S: {cert_type,client_cert, response_data}client_write_key
          server-finish		S -> C: {session_id}server_write_key

In this last exchange, the response_data is a function of the auth_type. (These tables are taken verbatim from the SSL Specification, Section numbers as indicated.)

There are some errors defined for the handshake. They are NO-CIPHER-ERROR, client NO-CERTIFICATE-ERROR, BAD-CERTIFICATE-ERROR, and UNSUPPORTED_CERTIFICATE_TYPE. NO-CIPHER occurs when the client and server can't agree on a cipher. (It is not clear why SSL doesn't require support for some simple cipher, such as RC4-40.) The other errors are recoverable if the client is the one with the bad certificate.

3. Keys used in SSL
There are a number of keys used over the course of a conversation. There is the server's public key, a master key, a client-read-key and a client-write-key. (The standard uses the term server-write-key as another name for client-read-key, and server-read-key as another name for client-write-key.)

Client-write-key and client-read-key are derived via a secure hash from the master key, an ordinal character, the challenge, and connection-id. Of this input, only the master key is sent encrypted (with the server's public key.) The master key is reused across sessions, while the read- & write- keys are generated anew for each session.

Two or more sets of key material are generated, based on how many bits of key are needed. Hash tends to be MD5, but is not required to be so by the spec. It is MD5 for all cipher types currently defined.

key-material-N = hash (master key, "N", challenge, connection-id) Keys are taken from the output of these hashes. Because of the design of secure hashes, changing 'N' will result in the output of these hashes being very different.

4. SSL Application Protocol
Once the handshaking is complete, the application protocol begins to operate. The SSL spec is not clear at what point the SSL connection is considered to be done with a connection, nor what to do with the keys at that point. There is an implication that the session is done when the TCP connection is torn down, and keys should be kept for roughly 100 seconds after that, but this is not explicitly defined.

5. Other details
SSL uses a scheme of https to reference documents available under HTTP with SSL. The https has a IANA reserved number of 443. SSL supports the RC2 & RC4 with either 128 bits or 40 bits of secret key information, as well as DES, 3 key 3DES, and IDEA. Details of all are covered in Schneier.

C. The threats

As long as they confine themselves to playing by the rules established by Netscape, lookers can do little harm. There's little a looker with minimal resources can do against the deployed crypto systems used in SSL. Hacking one or more of the hosts or key certification authorities would seem to be a better option.

Insiders, especially those around the top of the key certification hierarchy, have the potential to do quite a bit of harm by creating false signatures on keys. Few of these attacks will occur in a vengeful manner; they require time and foresight to enact, and are probably the domain of the malicious employee. (This assumes that employees who become vengeful do so at about the time they leave a firm.)

A criminal organization could, depending on its resources, possibly target an employee at a key certification organization. However, a more useful option might be to buy a cheap PC, and have it attempt brute force RC4 keys. It is estimated that a pentium based PC should be able to crack a 40 bit RC4 key in a month or several months using brute force. The manipulations used on the master key may increase the cost of tha attack, but probably not by orders of magnitude. If a PC costs $1500, then breaking 12 keys a year leads to a cost that could be as low as $125 per stolen card number. While this seems like a high price, the credit card numbers are acquired in a nearly risk free manner of sniffing an ethernet. In addition, that time will drop with the introduction of faster hardware.

D. Protections

SSL explicitly examines a number of attacks that can be made against it, including brute force, clear text cryptanalysis, replay, and man in the middle. It does seem to protect well against those forms of attack.

SSL is designed to protect at the network layer. This means it is not designed to, and does not, protect you from host breakins. To protect against host breakins, a Tripwire-like package should be integrated with the HTTPd. Tripwire uses cryptographically strong hashes to ensure documents have not been changed from some reference version. The database is usually stored on a physically write protected media like a floppy (Kim).

E. Weaknesses

SSL, being a low level protocol, does little to protect you once your host is compromised. Also, once a key in a certificate is compromised, it can remain compromised, as there is no mechanism in place for consulting the root of a CA to confirm the key you are using has not been revoked. The keys however do include expiration dates. Climbing to the root CA is not a commonplace step, but a mechanism should be available to do so, for high value transactions. Out of band key repudiation is also desirable. Today, trusted key certifiers are compiled into the Netscape binary.

The use of RC4 is troublesome, albeit understandable. RC4 is a newly published cipher, and although it was designed by the very competent Ron Rivest, it has not been subjected to the same kind of intense professional scrutiny that DES and IDEA have undergone. The decision to use RC4-40 is driven by the fact that it gets automatic export approval from the State Department.

There are also a number of areas in the design of SSL as it stands that could become exploitable problems. None suggest an immediate means of attack, but are things which could be modified for possible added surety.

Handshaking protocol: The challenge data, sent in the CLIENT-HELLO message, could in some types of handshakes, be sent later, encrypted. The data used in generating the session keys could include more data not sent in the clear. The means of generating the master key should be better specified, probably with reference to RFC-1750.

Record protocol: Bad MAC-data should not terminate a connection, it should cause a repeat-request message. There are few attacks that will get anything from having the same data resent, and closing the connection on a bad message opens avenues for denial of service attacks. Sequence numbers should be randomly initialized. There are quite a few non-obvious attacks on sequence numbers (in IP, and NFS); it can't hurt to start with a non-predictable number.

There should be a way for one or both sides to demand renegotiation of keys. Perhaps this could be implemented as a security escape. This is not needed for HTTP connection security, since the connections are very short lived, but if SSL is used, as the authors suggest, for telnet or FTP, the sessions could last substantially longer.