Internet & Intranet Security

15.2 SSL PROTOCOL

In general, there are several possibilities to cryptographically protect HTTP data traffic. For example, in the early 1990s the CommerceNet consortium proposed Secure HTTP (S-HTTP). As will be briefly mentioned in Chapter 16, S-HTTP was basically a security-specific enhancement of HTTP. An implementation of S-HTTP was made publicly available in a modified version of the NCSA Mosaic browser that users had to purchase (contrary to the "normal" NCSA Mosaic browser that was publicly and freely available on the Internet). At the same time, however, Netscape Communications introduced SSL and a protocol of the same name with the first version of Netscape Navigator.^[1] Contrary to the CommerceNet consortium, Netscape Communications did not charge its customers for the implementation of its security protocol. Consequently, SSL became the predominant protocol to provide security services for HTTP data traffic after 1994, and S-HTTP silently sank into oblivion.

So far, we have seen three versions of SSL:

• SSL version 1.0 was used internally only by Netscape Communications. It contained some serious flaws and was never released in public.

• SSL version 2.0 was incorporated into Netscape Navigator versions 1.0 through 2.x. It had some weaknesses related to specific incarnations of the man-in-the-middle attack. In an attempt to leverage public uncertainty about SSL's security, Microsoft also introduced the competing Private Communication Technology (PCT) protocol in its first release of its Internet Explorer in 1996.

• Netscape Communications responded to Microsoft's PCT challenge by introducing SSL version 3.0 that addressed the problems in SSL 2.0 and added some new features. At this point, Microsoft backed down and agreed to support SSL in all versions of its TCP/IP-based software (although its own software still supports PCT for backward compatibility).

The latest specification of SSL 3.0 was officially released in March 1996. It is implemented in both Netscape Navigator 3.0 (and higher) and Microsoft Internet Explorer 3.0 (and higher). As discussed later in this chapter, SSL 3.0 has also been adapted by the IETF Transport Layer Security (TLS) WG. In fact, the TLS 1.0 protocol specification is a derivative of SSL 3.0.

The architecture of SSL and the corresponding SSL protocol are illustrated in Figure 15.1. According to this figure, SSL refers to an intermediate (security) layer between the transport layer and the application layer. SSL is layered on top of a connection-oriented and reliable transport service, such as provided by TCP. It is conceptually able to provide security services for arbitrary TCP-based application protocols, not just HTTP. As a matter of fact, one major advantage of transport layer security protocols in general, and the SSL protocol in particular, is that they are application-independent, in the sense that they can be used to transparently secure any application protocol layered on top of TCP. Figure 15.1 illustrates several exemplary application protocols, including NSIIOP, HTTP, FTP, Telnet, IMAP, IRC, and POP3. They can all be secured by layering them on top of SSL (the appended letter "S" in the corresponding protocol acronyms indicates the use of SSL). Note, however, that SSL has a strong client-server orientation and does not really meet the requirements of peer application protocols.

Figure 15.1: The architecture of SSL and the SSL protocol.

In short, the SSL protocol provides communication security that has three basic properties:

1. The communicating parties (i.e., the client and the server) can authenticate each other using public key cryptography.

2. The confidentiality of the data traffic is protected, as the connection is transparently encrypted after an initial handshake and session key negotiation has taken place.

3. The authenticity and integrity of the data traffic is also protected, as messages are transparently authenticated and integrity-checked using MACs.

Nevertheless, it is important to note that SSL does not protect against traffic analysis attacks. For example, by examining the unencrypted source and destination IP addresses and TCP port numbers, or examining the volume of transmitted data, a traffic analyst can still determine what parties are interacting, what types of services are being used, and sometimes even recover information about business or personal relationships. We have already mentioned in this book that users generally consider the threat of traffic analysis to be relatively low, and so the developers of SSL have not attempted to address it, either. Furthermore, SSL does not protect against attacks directed against the TCP implementation, such as TCP SYN flooding or session hijacking attacks.

To use SSL protection, both the client and server must know that the other side is using SSL. In general, there are three possibilities to address this issue:

1. Use dedicated port numbers reserved by the IANA. In this case, a separate port number must be assigned for every application protocol that uses SSL.

2. Use the normal port number for every application protocol, and to negotiate security options as part of the (now slightly modified) application protocol.

3. Use a TCP option to negotiate the use of a security protocol, such as SSL, during the normal TCP connection establishment phase.

The application-specific negotiation of security options (i.e., the second possibility) has the disadvantage of requiring each application protocol to be modified to understand the negotiation process. Also, defining a TCP option (i.e., the third possibility) would be a fine solution, but has not been seriously discussed so far. In practice, separate port numbers have been reserved and assigned by the IANA for every application protocol that may run on top of SSL or TLS (i.e., the first possibility).^[2] Note, however, that the use of separate port numbers also has the disadvantage of requiring two TCP connections if the client does not know what the server supports. First the client must connect to the secure port, and then to the unsecure port, or vice versa. It is very possible that future protocols will abandon this approach and go for the second possibility. For example, the Simple Authentication and Security Layer (SALS) defines a method for adding authentication support to connection-based application protocols [5]. According to the SALS specification, the use of authentication mechanisms is negotiable between the client and server of a given application protocol. As of this writing, SALS is primarily used to secure communications between IMAP4 clients and servers. It is not clear at the moment whether SALS or similar mechanisms will also be used to secure other application protocols.

The port numbers assigned by the IANA for application protocols that run on top of SSL/TLS are summarized in Table 15.1 and partly illustrated in Figure 15.1. Note that some acronyms for application protocols that run on top of SSL/TLS have changed since the publication of the first edition of this book. Today, the "S" indicating the use of SSL is consistently appended (postfixed) to the acronyms of the corresponding application protocols (in some earlier terminologies, the "S" was inconsistently used and prepended (prefixed) to some acronyms).

In general, an SSL session is stateful and the SSL protocol must initialize and maintain the state information on either side of the session. The corresponding session state information elements, including a session ID, a peer certificate, a compression method, a cipher spec, a master secret, and a flag that indicates whether the session is resumable, are summarized in Table 15.2. An SSL session can be used for several connections, and the corresponding connection state information elements are summarized in Table 15.3. They include cryptographic parameters, such as server and client random byte sequences, server and client write MAC secrets, server and client write keys, an initialization vector, and a sequence number. In either case, it is important to note that communicating parties may use multiple simultaneous SSL sessions and sessions with multiple simultaneous connections.

As illustrated in Figure 15.1, the SSL protocol consists of two main parts, the SSL Record Protocol and several SSL subprotocols layered on top of it:

• The SSL Record Protocol is layered on top of a connection-oriented and reliable transport layer service, such as provided by TCP, and provides message origin authentication, data confidentiality, and data integrity services (including such things as replay protection).

• The SSL subprotocols are layered on top of the SSL Record Protocol to provide support for SSL session and connection establishment management.

The most important SSL subprotocol is the SSL Handshake Protocol. This protocol, in turn, is an authentication and key exchange protocol that can be used to negotiate, initialize, and synchronize security parameters and corresponding state information located at either endpoint of an SSL session or connection.

After the SSL Handshake Protocol has completed, application data can be sent and received using the SSL Record Protocol and the negotiated security parameters and state information elements. The SSL Record and Handshake Protocols are overviewed next.

15.2.1 SSL Record Protocol

The SSL Record Protocol receives data from higher layer SSL subprotocols and addresses data fragmentation, compression,^[3] authentication, and encryption. More precisely, the protocol takes as input a data block of arbitrary size, and produces as output a series of SSL data fragments (further referred to as SSL records) of less than or equal to 2¹⁴ − 1 = 16,383 bytes each.

The various steps of the SSL Record Protocol that lead from a raw data fragment to an SSLPlaintext (fragmentation step), SSLCompressed (compression step), and SSLCiphertext (encryption step) record are illustrated in Figure 15.2. Finally, each SSL record contains the following information fields:

• Content type;

• Protocol version number;

• Length;

• Data payload (optionally compressed and encrypted);

• MAC.

Figure 15.2: The SSL Record Protocol steps.

The content type defines the higher layer protocol that must be used to subsequently process the SSL record data payload (after proper decompression and decryption). The protocol version number determines the SSL version in use (typically 3.0). Each SSL record data payload is compressed and encrypted according to the current compression method and cipher spec defined for the SSL session. At the start of each SSL session, the compression method and cipher spec are usually defined as null. They are both set during the initial execution of the SSL Handshake Protocol. Finally, a MAC is appended to each SSL record. It provides message origin authentication and data integrity services. Similar to the encryption algorithm, the algorithm that is used to compute and verify the MAC is defined in the cipher spec of the current session state. By default, the SSL Record Protocol uses a MAC construction that is similar but still different from the newer HMAC construction specified in RFC 2104 [6]. There are three major differences between the SSL MAC construction and the HMAC construction:

1. The SSL MAC construction includes a sequence number in the message before hashing to protect against specific forms of replay attacks.

2. The SSL MAC construction includes the record length.

3. The SSL MAC construction uses concatenation operators, whereas the HMAC construction uses the addition modulo 2.

All these differences exist mainly because the SSL MAC construction predates the adoption of the HMAC construction in almost all Internet security protocol specifications. The HMAC construction was also adopted for the more recent TLS protocol specification.

As illustrated in Figure 15.1, several SSL subprotocols are layered on top of the SSL Record Protocol. Each subprotocol may refer to specific types of messages that are sent using the SSL Record Protocol. The SSL 3.0 specification defines the following three SSL protocols:

• Alert Protocol;

• Handshake Protocol;

• ChangeCipherSpec Protocol.

In short, the SSL Alert Protocol is used to transmit alerts (i.e., alert messages) via the SSL Record Protocol. Each alert message consists of two parts, an alert level and an alert description.

The SSL Handshake Protocol is the major SSL subprotocol. It is used to mutually authenticate the client and the server and to exchange a session key. As such, the SSL Handshake Protocol is overviewed and briefly discussed in the following section.

Finally, the SSL ChangeCipherSpec Protocol is used to change between one cipher spec and another. Although the cipher spec is normally changed at the end of an SSL handshake, it can also be changed at any later point in time.

In addition to these SSL subprotocols, an SSL Application Data Protocol is used to directly pass application data to the SSL Record Protocol.

15.2.2 SSL Handshake Protocol

The SSL Handshake Protocol is the main SSL subprotocol that is layered on top of the SSL Record Protocol. Consequently, SSL handshake messages are supplied to the SSL record layer, where they are encapsulated within one or more SSL records, which are processed and transmitted as specified by the compression method and cipher spec of the current SSL session, and the cryptographic keys of the corresponding SSL connection. The aim of the SSL Handshake Protocol is to have a client and server establish and maintain state information that is used to secure communications. More specifically, the protocol is to have the client and server agree on a common SSL protocol version, select the compression method and cipher spec, optionally authenticate each other, and create a master secret from which the various session keys for message authentication and encryption may be derived.

In short, an execution of the SSL Handshake Protocol between a client C and a server S can be summarized as follows (the messages that are put in square brackets are optional):

When the client C wants to connect to the server S, it establishes a TCP connection to the HTTPS port (not included in the protocol description) and sends a CLIENTHELLO message to the server in step 1 of the SSL Handshake Protocol execution. The client can also send a CLIENTHELLO message in response to a HELLOREQUEST message or on its own initiative to renegotiate the security parameters of an existing connection. The CLIENTHELLO message includes the following fields:

• The number of the highest SSL version understood by the client (typically 3.0);

• A client-generated random structure that consists of a 32-bit timestamp in standard UNIX format, and a 28-byte value generated by a pseudorandom number generator;

• A session identity the client wishes to use for this connection;

• A list of cipher suites that the client supports;

• A list of compression methods that the client supports.

Note that the session identity field should be empty if no SSL session currently exists or if the client wishes to generate new security parameters. In either case, a nonempty session identity field is to specify an existing SSL session between the client and the server (i.e., a session whose security parameters the client wishes to reuse). The session identity may be from an earlier connection, this connection, or another currently active connection. Also note that the list of supported cipher suites, passed from the client to the server in the CLIENTHELLO message, contains the combinations of cryptographic algorithms supported by the client in order of preference. Each cipher suite defines both a key exchange algorithm and a cipher spec. The server will select a cipher suite or, if no acceptable choices are presented, return an error message and close the connection accordingly. After having sent the CLIENTHELLO message, the client waits for a SERVERHELLO message. Any other message returned by the server except for a HELLOREQUEST message is treated as an error at this point in time.

In step 2, the server processes the CLIENTHELLO message and responds with either an error or SERVERHELLO message. Similar to the CLIENTHELLO message, the SERVERHELLO message includes the following fields:

• A server version number that contains the lower version of that suggested by the client in the CLIENTHELLO message and the highest supported by the server;

• A server-generated random structure that also consists of a 32-bit timestamp in standard UNIX format, and a 28-byte value generated by a pseudorandom number generator;

• A session identity corresponding to this connection;

• A cipher suite selected by the server from the list of cipher suites supported by the client;

• A compression method selected by the server from the list of compression algorithms supported by the client.

If the session identity in the CLIENTHELLO message was nonempty, the server looks in its session cache for a match. If a match is found and the server is willing to establish the new connection using the corresponding session state, the server responds with the same value as supplied by the client. This indicates a resumed session and dictates that both parties must proceed directly to the CHANGECIPHERSPEC and FINISHED messages as addressed further below. Otherwise, this field contains a different value identifying a new session. The server may also return an empty session identity field to indicate that the session will not be cached and therefore cannot be resumed later. Also note that in the SERVERHELLO message, the server selects a cipher suite and a compression method from the lists provided by the client in the CLIENTHELLO message. The key exchange, authentication, encryption, and message authentication algorithms are determined by the cipher suite selected by the server and revealed in the SERVERHELLO message. The cipher suites that have been defined for the SSL protocol are essentially the same as the ones that are specified for the TLS protocol (as summarized in Tables 15.4 to 15.7).

In addition to the SERVERHELLO message, the server may also send other messages to the client. For example, if the server is using certificate-based authentication (which is currently almost always the case), the server sends its site certificate to the client in a corresponding CERTIFICATE message. The certificate type must be appropriate for the selected cipher suite's key exchange algorithm, and is generally an X.509v3 certificate. The same message type will be used later for the client's response to the server's CERTIFICATEREQUEST message. In the case of X.509v3 certificates, a certificate may actually refer to an entire chain of certificates, ordered with the sender's certificate first followed by any CA certificates proceeding sequentially upward to a root CA (that will be accepted by the client).

Next, the server may send a SERVERKEYEXCHANGE message to the client if it has no certificate, a certificate that can be used only for verifying digital signatures, or uses the FORTEZZA token-based key exchange algorithm (KEA).^[4] Obviously, this message is not required if the site certificate includes an RSA public key that can be used for encryption. Also, an unanonymous server can optionally request a personal certificate to authenticate the client. It therefore sends a CERTIFICATEREQUEST message to the client. The message includes a list of the types of certificates requested, sorted in order of the server's preference, as well as a list of distinguished names for acceptable CAs. At the end of step 2, the server sends a SERVERHELLODONE message to the client to indicate the end of the SERVERHELLO and associated messages.

Upon receipt of the SERVERHELLO and associated messages, the client verifies that the server provided a valid site certificate,^[5] if required, and checks that the security parameters provided in the SERVERHELLO message are indeed acceptable. If the server has requested client authentication, it sends a CERTIFICATE message that includes a personal certificate for the user's public key to the server in step 3. Next, the client sends a CLIENTKEYEXCHANGE message, whose format depends on the key exchange algorithm selected by the server:

• If RSA is used for server authentication and key exchange, the client generates a 48-byte premaster secret,^[6] encrypts it with the public key found in the site certificate or the temporary RSA key from the SERVERKEYEXCHANGE message, and sends the result back to the server in the CLIENTKEYEXCHANGE message. The server, in turn, uses the corresponding private key to decrypt the premaster secret. We will return to this key exchange algorithm later in this section when we talk about a specific attack.

• If FORTEZZA tokens are used for key exchange, the client derives a token encryption key (TEK) using the KEA. The client's KEA calculation uses the public key from the server certificate along with some private parameters in the client's token. The client sends public parameters needed for the server to also generate the TEK, using its private parameters. It generates a premaster secret, wraps it using the TEK, and sends the result together with some initialization vectors to the server as part of the CLIENTKEYEXCHANGE message. The server, in turn, can decrypt the premaster secret accordingly. This key exchange algorithm is not widely used in practice.

• If a Diffie-Hellman key exchange is performed, the server and client exchange their public parameters as part of the SERVERKEYEXCHANGE and CLIENTKEYEXCHANGE messages. Obviously, this is only required if the Diffie-Hellman public parameters are not included in the site and personal certificates. The negotiated Diffie-Hellman key can then be used as premaster secret. Because a Diffie-Hellman key exchange involves both parties in a key exchange, the resulting key exchange is less vulnerable to weak pseudorandom number generators in client software packages. Consequently, it is possible and very likely that we will see more widespread use of the Diffie-Hellman key exchange in the future.

For RSA, FORTEZZA, and Diffie-Hellman key exchange, the same algorithms are used to convert the premaster secret into a 48-byte master secret (stored in the corresponding SSL session state), and to derive session keys for encryption and message authentication from this master secret. Nevertheless, some key exchange algorithms, such as FORTEZZA token-based key exchange, may also use their own procedures for generating encryption keys. In this case, the master secret is only used to derive keys for message authentication. The procedures to derive master and session keys, as well as initialization vectors, are fully described in the SSL protocol specification and are not further addressed in this book.

If client authentication is required, the client also sends a CERTIFICATEVERIFY message to the server. This message is used to provide explicit verification of the user's identity based on the personal certificate. It is only sent following a client certificate that has signing capability (all certificates except those containing fixed Diffie-Hellman parameters). Finally, the client finishes step 3 by sending a CHANGECIPHERSPEC message and a corresponding FINISHED message to the server. The FINISHED message is always sent immediately after the CHANGECIPHERSPEC message to verify that the key exchange and authentication processes were successful. As a matter of fact, the FINISHED message is the first message that is protected with the newly negotiated algorithms and session keys. It can only be generated and verified if these keys are properly installed on both sides. No acknowledgment of the FINISHED message is required; parties may begin sending encrypted data immediately after having sent the FINISHED message. The SSL Handshake Protocol execution finishes up by also having the server send a CHANGECIPHERSPEC message and a corresponding FINISHED message to the client in step 4.

After the SSL handshake is complete, a secure connection is established between the client and the server. This connection can now be used to send application data that is encapsulated by the SSL Record Protocol. More accurately, application data may be fragmented, compressed, encrypted, and authenticated according to the SSL Record Protocol, as well as the session and connection state information that is now established (according to the execution of the SSL Handshake Protocol).

The SSL Handshake Protocol can be shortened if the client and server decide to resume a previously established (and still cached) SSL session or duplicate an existing SSL session. In this case, only three message flows and a total of six messages are required. The corresponding message flows can be summarized as follows:

In step 1, the client sends a CLIENTHELLO message to the server that includes a session identity to be resumed. The server, in turn, checks its session cache for a match. If a match is found, and the server is willing to resume the connection under the specified session state, it returns a SERVERHELLO message with the same session identity in step 2. At this point, both the client and the server must send CHANGECIPHERSPEC and FINISHED messages to each other in steps 2 and 3. Once the session reestablishment is complete, the client and server can begin exchanging application data.

In summary, the SSL protocol can be used to establish secure TCP connections between clients and servers. In particular, it can be used to authenticate the server, to optionally authenticate the client, to perform a key exchange, and to provide message authentication, as well as data confidentiality and integrity services for arbitrary application protocols layered on top of TCP. Although it may seem that not providing client authentication goes against the principles that should be espoused by a secure system, an argument can be made that the decision to optionally support it helped SSL gain widespread use in the first place. Support for client authentication requires public keys and personal certificates for each client, and because SSL support for HTTP must be embedded in the corresponding browser software, requiring client authentication would involve distributing public keys and personal certificates to every user on the Internet. In the short term, it was believed to be more crucial that consumers be aware of with whom they are conducting business than to give the merchants the same level of assurance. Furthermore, because the number of Internet servers is much smaller than the number of clients, it is easier and more practical to first outfit servers with the necessary public keys and site certificates. As of this writing, however, support for client-side public keys and personal certificates is growing as people generally push the use of PKI technologies.

A comprehensive security analysis of SSL 3.0 was performed by Bruce Schneier and David Wagner in [7]. Except for some minor flaws and worrisome features that could be easily corrected without overhauling the basic structure of the SSL protocol, they found no serious vulnerability or security problem in their analysis. Consequently, they concluded that the SSL protocol provides excellent security against eavesdropping and other passive attacks, and that people implementing the protocol should be aware of some sophisticated active attacks.

In 1998, Daniel Bleichenbacher from Bell Laboratories found an adaptive chosen ciphertext attack against protocols based on the public key cryptography standard (PKCS) #1 [8]. In short, an RSA private key operation (a decryption or digital signature operation) can be performed if the attacker has access to an oracle that, for any chosen ciphertext, returns only 1 bit telling whether the ciphertext corresponds to some unknown block of data encrypted using PKCS #1 [9]. Because this attack is quite sophisticated and requires some basic understanding of cryptanalysis, you may skip the following paragraphs and continue to read Section 15.3, which addresses currently available SSL implementations.

To understand the Bleichenbacher attack, it is necessary to have a look at PKCS #1. In fact, there are three block formats specified in PKCS #1: block types 0 and 1 are used for RSA digital signatures, and block type 2 is used for RSA encryption. Recall from our previous discussion that if the RSA algorithm is used for server authentication and key exchange, the client randomly generates a 46-byte premaster secret, prepends the two bytes 03 (the SSL protocol version number) and 00 to the premaster secret, encrypts the result using the public key of the server, and sends it in a CLIENTKEYEXCHANGE message to the server. As such, the CLIENTKEYEXCHANGE message carrying the encrypted premaster secret must conform to the format specified in PKCS #1 block type 2. The format is illustrated in Figure 15.3.

Figure 15.3: PKCS #1 block format for encryption.

Now, assume there is an attacker who can send an arbitrary number of randomly looking messages to an SSL server, and the server responds for each of these messages with a bit indicating whether a particular message is correctly encrypted and encoded according to PKCS #1 (the server thus acts as an oracle). Under this assumption, Bleichenbacher developed an attack to illegitimately perform an RSA operation with the private key of the server (either a decryption or a digital signature operation). When applied to decrypt a premaster secret of a previously sent CLIENTKEYEXCHANGE message, the attacker can rebuild the premaster secret and the session keys that are derived from it accordingly. Consequently, the attacker can then decrypt the entire session (if he or she has monitored and stored the data stream of that session).

The attack is primarily of theoretical interest. Note that experimental results have shown that typically between 300,000 and 2 million chosen ciphertexts are required to actually perform the (decryption or digital signature) operation. To make things worse, the attack can only be launched against an SSL server that is available on-line (since it must act as an oracle). From the attacker's point of view, it may be difficult to send this huge number of chosen ciphertexts to the SSL server without causing the server administrator to become suspicious.

There are several possibilities to protect against the Bleichenbacher attack. First of all, it is not necessary for the server to respond with an error message after having received a CLIENTKEYEXCHANGE message that does not conform to PKCS #1. Another possibility is to change the PKCS #1 block format for encryption and to remove the leading 00 and 02 bytes, as well as the 00, 03, and 00 bytes in the middle of the message (as illustrated in Figure 15.3). Finally, another possibility is to use plaintext-aware encryption schemes, such as the one proposed by Mihir Bellare and Phillip Rogaway [10], or any other public key cryptosystem that is provably secure against adaptive chosen ciphertext attacks [11].^[7] For example, in the aftermath of the publication of Bleichenbacher's results, IBM launched a marketing initiative to promote such a cryptosystem jointly developed by Ronald Cramer and Victor Shoup [12].

Before Bleichbacher published his attack, he had been collaborating with RSA Laboratories to update PKCS #1 and to specify a version 2 that is secure against adaptive chosen ciphertext attacks [13]. Meanwhile, all major vendors of SSL servers have incorporated and implemented PKCS #1 version 2 into their products. As a result, this attack does not work anymore due to recent releases of SSL server software.

Finally, it may be interesting to know that most banks that offer their services over the Internet have their corresponding home banking client software based on SSL. This decision also conforms to the strategic view of the European Committee for Banking Standards (ECBS) [14]. As of this writing, the SSL protocol is by far the most pervasive security protocol for the Internet in general, and the WWW in particular. In fact, many Web servers and browsers have been modified to use SSL. For example, the Apache Web server has been modified to incorporate the SSLeay mentioned below [15]. Typically, Web servers that use SSL (or TLS) are called "secure" or "commerce servers." Note, however, that these servers are not necessarily more secure than any other Web server; they just support SSL to secure the data traffic that is transmitted between the client and the server. On the client side, most browsers support SSL. In particular, Netscape Navigator and Microsoft Internet Explorer both provide support for SSL. Most of these products support the RC4 algorithm for encryption and the MD2 and MD5 one-way functions for hashing. In addition, there are many implementations of SSL. Examples include SSLref, a reference implementation of SSL from Netscape Communications; SSLeay, an internationally distributed implementation written by Eric Young in Australia; and OpenSSL, an open source implementation of SSL.^[8] Finally, there is an interesting software called Stunnel that can be used to add SSL protection to existing TCP-based application servers in a UNIX environment without requiring changes to the corresponding code. The software can be invoked from the Internet daemon (i.e., inetd) as a wrapper for any number of services or run standalone, accepting network connections itself for a particular service. Refer to the Stunnel home page^[9] for further information about the software package.

For obvious reasons, the use of SSL slows the speed of a browser interacting with an HTTPS server. This performance degradation is in fact noticeable by the user. It is primarily due to the public key encryption and decryption operations that are required to initialize the SSL session and connection state information elements. In practice, users experience an additional pause of a few seconds between opening a connection to the HTTPS server and retrieving the first HTML page from it. Because SSL is designed to cache the master secret between subsequent sessions, this delay affects only the first SSL connection between the browser and the server. Compared with the session establishment, the additional overhead of encrypting and decrypting the data traffic using one of the supported encryption algorithms, such as DES, RC2, or RC4, is practically insignificant (and not necessarily noticeable by the user). Consequently, for users that have a fast computer and a relatively slow network connection to an HTTPS server, the overhead of SSL is insignificant, especially if a large amount of data is sent afterward over the SSL session or over multiple SSL sessions that use a shared master secret. However, administrators of very busy SSL servers should consider getting either extremely fast computers or hardware assistance for the public key operations.

^[1]On August 12, 1997, Netscape Communications was granted U.S. patent 5,657,390, "Secure Socket Layer Application Program Apparatus and Method" for the technology employed by the SSL protocol.

^[2]http://www.isi.edu/in-notes/iana/assignments/port-numbers

^[3]Data compression as addressed by the SSL Record Protocol is not supported by the major SSL implementations in use today.

^[4]Netscape Communications was paid a large amount of money by the NSA to include support for the FORTEZZA KEA in the SSL protocol specification.

^[5]A site certificate is considered to be valid if its server's common name field entry matches the host part of the URL the client wants to access.

^[6]The premaster secret is 48 bytes long and consists of 2 bytes specifying the protocol version and 46 bytes of randomly generated data.

^[7]Note that plaintext awareness always implies security against chosen ciphertext attacks.

^[8]http://www.openssl.org

^[9]http://www.stunnel.org