SSL is the Secure Sockets Layer, a general-purpose protocol for sending encrypted information over the Internet. Developed by Netscape, SSL was first popularized by Netscape’s web browser and web server. The idea was to stimulate the sales of the company’s cryptographically enabled web servers by distributing a free client that implemented the same cryptographic protocols.
Since then, SSL has been incorporated into many other web servers and browsers, and by now support for SSL is no longer a competitive advantage but a necessity. SSL has gone through two major versions. In 1996 the Internet Engineering Task Force Transport Layer Security (TLS) was established to create an open stream encryption standard. The group started with SSL 3.0 and, in 1999, published RFC 2246, “TLS Protocol Version 1.0.” RFC 2712 adds Kerberos authentication to TLS. RFC 2817 and 2818 apply to TLS using HTTP/1.1. This chapter introduces SSL and TLS. Appendix B provides detailed technical information.
SSL is a layer that exists between the raw TCP/IP protocol and the application layer. While the standard TCP/IP protocol simply sends an unauthenticated, error-free stream of information between two computers (or between two processes running on the same computer), SSL adds numerous features to that stream, including:
Authentication of the server, using digital signatures
Authentication of the client, using digital signatures
Data confidentiality through the use of encryption
Data integrity through the use of message authentication codes
Cryptography is a fast-moving field, and cryptographic protocols don’t work unless both parties to the communication use the same algorithms. For that reason, SSL is an extensible and adaptive protocol. When one program using SSL attempts to contact another, the two programs electronically compare notes, determining the strongest cryptographic protocol that they share in common. And this exchange is called the SSL Hello .
SSL was designed for use worldwide, but it was developed in the United States when the U.S. restricted the export of strong cryptography. For this reason, SSL was designed with many features intended to conform with the U.S. government’s older, more restrictive policies on the export of cryptographic systems (described in Chapter 4).
The SSL protocol was designed by Netscape for use with Netscape Navigator. Version 1.0 of the protocol was used inside Netscape. Version 2.0 of the protocol shipped with Netscape Navigator Versions 1 and 2. After SSL 2.0 was published, Microsoft created a similar secure link protocol called PCT, which overcame some of SSL 2.0’s shortcomings. The advances of PCT were echoed in SSL 3.0. The SSL 3.0 protocol is the basis for the TLS protocol developed by the IETF. Implementations of SSL 3.0/TLS are present in Netscape Navigator, Microsoft Windows, and the open source OpenSSL library.
This chapter describes SSL 3.0 and TLS, which are essentially the same protocol.[73]
SSL/TLS offers many features of both practical and theoretical interest:
- Separation of duties
SSL/TLS uses separate algorithms for encryption, authentication, and data integrity with different keys (called secrets ) for each function. The primary advantage of this separation of duties is that the keys used for authentication and data integrity can be longer than the keys used for privacy. This was useful for products that were designed for export from the United States, because federal regulations formerly placed limitations on the lengths of keys used for confidentiality but not those used for data integrity and authentication.
SSLv3 and TLS allow for connections that are not encrypted but are authenticated and protected against deliberate tampering by a sophisticated attacker. This might be useful in circumstances where encryption is forbidden or severely restricted by law.
The choice of algorithms and key lengths is determined by the SSL server, but is limited by both the server and the client.
- Efficiency
Public key encryption and decryption is a time-consuming operation. Rather than repeat this process for every communication between a client and a server, SSL/TLS implementations can cache a “master secret” that is preserved between connections. This allows new connections to immediately begin secure communications, without the need to perform more public key operations.
- Certificate-based authentication
SSL/TLS provides for authentication of both the client and the server through the use of digital certificates and digitally signed challenges. SSLv3 and TLS use X.509 v3 certificates. Authentication is an optional part of the protocol, although server certificates are effectively mandated by today’s client implementations.
- Protocol agnostic
Although SSL was designed to run on top of TCP/IP, it can in fact run on top of any reliable connection-oriented protocol, such as X.25 or OSI. The SSL protocol cannot run on top of a nonreliable protocol such as the IP User Datagram Protocol (UDP). All SSL/TLS communication takes place over a single bidirectional stream. In the case of TCP/IP, the ports listed in Table 5-1 are commonly used.
Table 5-1. TCP/IP ports used by SSL-protected protocols
Keyword | Decimal port | Purpose |
|---|---|---|
https | 443/tcp | SSL/TLS-protected HTTP |
ssmtp | 465/tcp | SSL/TLS-protected SMTP (mail sending) |
snews | 563/tcp | SSL/TLS-protected Usenet news |
ssl-ldap | 636/tcp | SSL/TLS-protected LDAP |
spop3 | 995/tcp | SSL-/TLS-protected POP3 (mail retrieving) |
- Protection against man-in-the-middle and replay attacks
The SSL/TLS protocol was specifically designed to protect against both man-in-the-middle and replay attacks. In a man-in-the-middle attack , an attacker intercepts all of the communications between two parties, making each think that it is communicating with the other (see Figure 5-1).
SSL/TLS protects against man-in-the-middle attacks by using digital certificates to allow the web user to learn the validated name of the web site. Unfortunately, every web browser used today hides this information, making it accessible only to users who use special, arcane commands. A better user interface would display the web site’s validated name in the title bar of the web browser, or in some other obvious place.[74] Because the certificate information is normally hidden, SSL does a poor job protecting users from man-in-the-middle attacks. See the next section for a discussion of SSL’s limitations.
In a replay attack , an attacker captures the communications between two parties and replays the messages. For example, an attacker might capture a message between a user and a financial institution instructing that an electronic payment be made; by replaying this attack, the attacker could cause several electronic payments to be made (see Figure 5-2).
- Support for compression
Because encrypted data cannot be compressed,[75] SSL/TLS provides for the ability to compress user data before it is encrypted. The protocol supports multiple compression algorithms.
- Backwards compatibility with SSL 2.0
SSLv3.0 servers can receive connections from SSLv2.0 clients and automatically handle the message without forcing the client to reconnect.
SSL actually does little to protect against the real attacks that consumers and merchants have experienced on the Internet—largely because SSL (and Netscape, by extension) did not attempt to solve the hard security problems of Internet commerce, but instead focused on problems that were easy to solve. Figure 5-3 shows estimates of the ease of various types of attacks on e-commerce credit card transactions. Of these attacks, SSL provides no protection against what are by far the most common threats, attacks on clients and merchants.
Real consumer protection on the Internet comes from Regulation E and Regulation Z and the policies of companies like VISA, MasterCard, American Express, and others that implement these policies. If you shop on the Internet with your credit card, and discover a fraudulent charge on your statement a month later, you can call up your credit card company and dispute the charge. This protection works not just against fraud but also against merchants that deliver defective or misrepresented products.
Consumers who use debit cards have less protection because the money has already been taken out of the consumer’s bank account, and in this case, he or she must fight to get it back. And consumers who use Electronic Funds Transfer (EFT) or Automated Clearing House (ACH) systems have no protection at all.
SSL/TLS makes extensive use of public key certificates to authenticate both the client and the server in SSL/TLS transactions. SSL/TLS makes use of both X.509 v3 certificates and Diffie-Helman certificates for holding encryption key pairs; SSL 3.0 also supports a modified X.509 certificate for holding public keys used by the U.S. Department of Defense Fortezza/DMS key exchange protocol.[76] Digital certificates are explained in detail in Chapter 7 and Chapter 17.
SSL supports the following kinds of certificates:
RSA public key certificates with public keys of arbitrary length
RSA public key certificates that are limited to 512 bits, designed for use in jurisdictions to restrict the use, export, or import of strong cryptography.
Signing-only RSA certificates, which contain RSA public keys that are used only for signing data, and not for encryption
DSS certificates
Diffie-Hellman certificates
Use of certificates is optional. SSL requires server certificates unless both the client and the server SSL implementations use the Diffie-Hellman key exchange protocol. Currently, Netscape products do not implement the Diffie-Hellman algorithms.
The Secure Sockets Layer was initially designed in July 1994. As we mentioned in Chapter 1, the protocol was fundamental to Netscape’s business plans. As the plan was originally presented, Netscape intended to give away a great browser that had the added benefit of allowing the user to perform encrypted communications with Netscape’s servers using Netscape’s proprietary protocol.
The first implementation of SSL was located in Netscape’s browsers and servers but never sold separately.
After the deployment of Netscape Navigator, Netscape produced a reference SSL implementation that would be distributable within the United States. That program, written in C, was called SSLRef. The 2.0 reference implementation was published in April 1995. Although the SSLRef source code was distributed freely within the United States on a noncommercial basis, it is no longer available. Netscape requests that individuals interested in SSLRef should instead use the Mozilla Network Security Services system.
Network Security Services (NSS) is a set of libraries designed to support cross-platform development of security-enabled server applications. Applications built with NSS can support SSLv2 and SSLv3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 v3 certificates, and other security standards. NSS is the cryptographic package that powers Netscape Navigator 6.0, server products from iPlanet E-Commerce Solutions, and other products. The source code is available for free and under a generous license agreement. For further information, consult http://www.mozilla.org/projects/security/pki/nss/.
SSLeay was an independent implementation of SSL 3.0 developed by Eric A. Young and Tim Hudson, two computer programmers in Australia. It was made freely available around the world on a number of anonymous FTP sites.
SSLeay used implementations of the RC2 and RC4 encryption algorithms based on the algorithms that were anonymously published on the Usenet sci.crypt newsgroup in September 1994 (RC4) and February 1996 (RC2). Young and Hudson eventually took jobs with RSA Data Security and used their SSLeay implementation as the basis of RSA’s SSL-C product. When they did, other volunteers took up the SSLeay project and renamed it OpenSSL.
OpenSSL is distributed under a generous license agreement. It is the basis of the SSL implementation in the Apache web server and numerous other products. It can be downloaded from http://www.openssl.org/.
There are also at least two implementations of SSL in Java:
Many versions of Java include the Java Cryptography Extensions, which provide a standardized set of classes that will encrypt and decrypt user-provided data. Two class hierarchies to explore are com.sun.crypto.provider.SunJCE and javax.crypto. For more information see the book Java Security by Scott Oaks (O’Reilly).
RSA Data Security offers JSAFE, a version of its BSAFE cryptography toolkit, but completely rewritten into Java. This toolkit includes high-speed implementations of the most popular encryption algorithms as well as RSA’s proprietary algorithms (e.g., RC2).
SSL noticeably slows the speed of transmitting information over the Internet. The performance degradation is primarily the result of the public key encryption and decryption that is required to initialize the first SSL connection. Compared with this, the additional overhead of encrypting and decrypting data using RC2, RC4, DES, or other algorithms is practically insignificant.
Users have reported performance degradations of approximately 50% when using SSL, compared to sending information in the clear. Users with current systems have reported that the public key encryption/decryption requires approximately less than three CPU seconds per user with a 1024-bit key.
This means there will be a few seconds pause between opening a connection to an SSL server and retrieving an HTML page from that server. Because SSL can cache the master key between sessions, the delay affects only the first SSL transaction between a client and a server.
If you have a fast computer and a relatively slow network connection—and who doesn’t?—the overhead of SSL can be insignificant, especially if you are sending large amounts of information over a single SSL session or over multiple SSL sessions that use a shared master secret.
On the other hand, if you expect to be serving dozens or more SSL HTTP requests over the course of a minute, consider getting either an extremely fast computer or hardware assistance for the public key operations.
To minimize the impact of SSL, many organizations transmit the bulk of their information in the clear, and use SSL only for encrypting the sensitive data. Unfortunately, this leaves the user open to attack, because the unencrypted HTML can be modified in transit as it is sent from the client to the server by a sophisticated packet filtering and injection program. (Graduate students at the University of California at Berkeley have already demonstrated how such a program can modify an executable program delivered on the fly over the network.)
For example, the action tag
in an HTML form could be changed so that instead of posting a credit
card number to a transaction processing system, the number is posted
to a pirate computer in South America. Assuming that the pirate
system’s operator can get a signed digital ID for his SSL server, it
may be very difficult for a user duped in this manner to detect that
she was the victim of an attack.
[73] TLS is actually version 3.1 of the SSL protocol.
[74] SSL does not protect against man-in-the-middle attacks when used in “encrypt-only” mode with any SSL_DH_anon cipher suite. That is because this mode allows neither the server nor the client to authenticate each other.
[75] Encrypted data cannot be compressed because good encryption effectively removes any of the repetition or self-similarity that is removed during compression. If your encrypted data can be compressed, then your encryption isn’t very good!
[76] Although SSLv3.0 supports the TLS U.S. Department of Defense Fortezza hardware encryption system, no such support is provided in the TLS standard.