5.1 What Is SSL?

only for RuBoard - do not distribute or recompile

5.1 What Is SSL?

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).

5.1.1 SSL Versions

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.[1]

[1] TLS is actually version 3.1 of the SSL protocol.

5.1.2 SSL/TLS Features

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.

Using SSL to Send Credit Card Numbers Securely

One of the most common questions asked by people new to SSL is, "How do I use SSL to send a credit card number securely?" The answer to this question is surprisingly straightforward assuming that you have a web server that is cryptographically enabled.

The whole point of SSL is to hide the complexities of cryptography from both users and developers. If your users are using an SSL-aware web browser, such as Netscape Navigator or Microsoft's Internet Explorer, you can instruct the browser to create an encrypted connection to your server simply by replacing the http in your URLs with https.

For example, say you have a proprietary document located at this URL:

http://www.company.com/document.html

Your users can obtain the document securely by requesting this URL:

https://www.company.com/document.html

Likewise, if you have a CGI form which allows people to submit sensitive information (such as a credit card number), you can force the information to be submitted cryptographically by simply modifying the action= clause in your HTML file, again changing the http: to https:.

For example, if the <form> tag in your HTML file looks like this:

<form method="POST" action="http://www.company.com/cgi-bin/enter">

simply change it to look like this:

<form method="POST" action="https://www.company.com/cgi-bin/enter">

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).

Figure 5-1. A man-in-the-middle attack
figs/wsc2_0501.gif

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.[2] 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.

[2] 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.

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).

Figure 5-2. A replay attack
figs/wsc2_0502.gif
Support for compression

Because encrypted data cannot be compressed,[3] SSL/TLS provides for the ability to compress user data before it is encrypted. The protocol supports multiple compression algorithms.

[3] 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!

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.

5.1.3 What Does SSL Really Protect?

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.

Figure 5-3. Estimated ease of various kinds of attacks on e-commerce credit card transactions
figs/wsc2_0503.gif

5.1.4 Digital Certificates

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.[4] Digital certificates are explained in detail in Chapter 7 and Chapter 17.

[4] Although SSLv3.0 supports the TLS U.S. Department of Defense Fortezza hardware encryption system, no such support is provided in the TLS standard.

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.

5.1.5 SSL Implementations

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.

5.1.5.1 SSL Netscape

The first implementation of SSL was located in Netscape's browsers and servers but never sold separately.

5.1.5.2 SSLRef and Mozilla Network Security Services

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/.

5.1.5.3 SSLeay and OpenSSL

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/.

5.1.5.4 SSL Java

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).

5.1.6 SSL Performance

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.

SSL/TLS URLs

Information about SSL can be found at:

http://www.ietf.org/rfc/rfc2246.txt

The TLS 1.0 protocol.

http://www.openssl.org/

The OpenSSL project.

http://www.mozilla.org/projects/security/pki/nss/

The Network Security Services project.

only for RuBoard - do not distribute or recompile


Web Security, Privacy & Commerce
Web Security, Privacy and Commerce, 2nd Edition
ISBN: 0596000456
EAN: 2147483647
Year: 2000
Pages: 194

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net