by Rik Farrow rik@spirit.com
In an uncertain world, it is nice to feel that we can rely on some things. The Secure Sockets Layer, SSL, provides a warm, fuzzy feeling for most Web browser users. SSL encrypts the data sent to servers using SSL, and can authenticate the identity of these servers as well. With all the failings discovered in software products, SSL appears to be a safe haven in an unpredictable world.
Unfortunately, SSL has a checkered past and present. Like other security problems involving encryption packages, the issues lie not so much in SSL as in the software used to implement and support it. Instead of guaranteeing security, SSL may provide a false sense of security through its occasional failings.
In his new book, Secrets and Lies, Bruce Schneier tells how he once felt that cryptography was the magic bullet that could solve all security problems. With hindsight and more experience, Schneier now writes that security is a process, not a product, and that cryptographic solutions, such as SSL, do not exist in a vacuum. In this column, I examine how SSL works, what it can do, and how the products and applications that use SSL have failed, resulting in updates to Netscape Navigator and Microsoft's Internet Explorer and IIS during the year 2000.
The HyperText Transfer Protocol (HTTP, RFC-2616) has very simple support for security. Web servers can refuse a connection from a client but give the client the opportunity to authenticate with a username and password. This mechanism does nothing to protect the password being sent over the Internet, nor to guarantee that the Web browser has even connected to the correct server. And any data transferred over HTTP can be sniffed, resulting in loss of secrets, such as credit card numbers, personal and corporate information.
As soon as HTTP became the main way in which people used the Internet, several groups published methods for securing Web interactions. The official project, sponsored by the IETF (Internet Engineering Task Force) was Secure HTTP (SHTTP, RFC 2660, see resources). There were also several unofficial projects, and one of these, created internally by Netscape, overwhelmed the sanctioned project by the sheer volume of users of Navigator. Today, SSL, Netscape's cryptographic solution, is still not an Internet standard, and is not even an RFC draft. You can find the description of SSL at Netscape's developers Web site, and find a free implementation at OpenSSL.org.
Both SHTTP and SSL protocols have three goals: to authenticate servers, to protect the confidentiality of data exchanged, and to guarantee the integrity of that data as well. A fourth goal, the ability to authenticate clients to servers, is included as well. Figure 1 demonstrates how this works with SSL.
You begin using SSL when you click on or enter a URL that begins with https instead of http. This commands the browser to connect to port 443, the default port used by SSL, instead of port 80. Your browser will also start the process of negotiating an SSL connection with the server by sending a Hello message. In the Hello message, the client tells the server which forms of encryption and compression it supports. The server, if it supports SSL, will respond by sending back its own Hello message and the selected encryption and compression methods, and including its certificate, along with some random numbers used later in the protocol.
The client checks the certificate it has received from the server to see if the common name stored in the certificate matches the name of the server it has connected to, and that the certificate itself is valid. The validation process involves checking the digital signature within the certificate using one of the list of Certifcate Authority public keys that either came with the browser, or were added later by the user. The client can end the connection if the certificate does not match the server name or is not signed by a Certificate Authority.
The client now sends along its own random value, and, depending on the key exchange protocol chosen, sends along either an encrypted secret or values used to determine that secret. This secret will be used to generate keys and values used while exchanging data, to encrypt the data, and to digitally sign the data (providing integrity and authentication of the data exchanged). The server may have also requested a certificate from the client, to be used to authenticate the user of the browser, but this is optional.
If the negotiations are successful, the browser sends the Web server a Finished message, and the server will respond with its own Finished message, and both sides are then ready to exchange encrypted and digitally signed data.
The business of key exchange takes a long time in computer terms. A 550 MHz Pentium III processor loaded with memory can perform one key exchange calculation in about 24 millesconds, or about 40 per second when using the RSA algorithm and 1024 bit keys when tested on a UNIX system. This value is rather optomistic, and under real conditions may be much slower (in the ten or 20 keys per second range). The key exchange calculations provide an upper limit on the number of new connections a busy Web server can make when using SSL.
The SSL protocol includes a feature to reduce the number of key exchanges necessary. If a Web browser makes another connection to the same SSL-enabled server, it can send a session identifier, and if the server accepts the identifier, it will use the previously negotiated encryption and compression algorithms and the current key. Netscape browsers can also include a keep-alive request, so that even after data has been exchanged, the TCP connection remains open for some time and can be used for future transactions without further negotiations.
SSL has been carefully thought out, and version three, the current version, includes many of the features that were in the IETF's SHHTP but were missing in the earlier versions of SSL (for example, negotiation of crypto algorithms for encryption and digital signatures). But that is not the same as saying there are no problems.
One of the most common problems with SSL has to do with the key length. Short keys can be "brute forced", that is, guessed by trying all possible key combinations. Forty bit keys have been guessed in less than one day using a handful of up-to-date PCs. And forty bit keys are what users of the International versions of Netscape and Internet Exporer are using. You can determine whether your version of Netscape has International "strength" encryption by watching the splash page when Netscape launches, or by selecting Help/About. Linux systems shipped from within the US, such as RedHat, come with limited key size (40 bits) because of export restrictions. If you live within the US or Canada, you want the US version that uses 128 bit keys for encryption.
Netscape has had other problems as well. In May of this year, Kevin Fu, a student at MIT, discovered that Navigator could be fooled into accepting invalid certificates. If a user visited a site that had a certificate where the server name did not match the common name found within the certificate, and the user chose to continue anyway (perhaps because the user did not intend to send anything sensitive to this site) Navigator would then fail to detect later mismatches in server names and the names stored within the certificates (see resources). Another problem, found by Mitja Kolsek of ACROS in Slovenia, resulted in CERT Advisory CA-2000-05. Kolsek discovered that Navigator assumed that a subsequent access to the same IP address was part of the same SSL session, but, through DNS spoofing, Navigator could be fooled into visiting a different site, foiling the mechanism that is supposed to guarantee that the server name matches the common name found in the server's certificate.
You can get a feel for what happens when you visit a site with a self-signed certificate (instead of one signed by one of the Certificate Authorities, such as Verisign or Thawte), by visiting https://snafu.fooworld.org/, a site maintained by Fu.
Microsoft has also had problems with SSL this year. IIS, both version 4 and 5, would send out the same session values in cookies for plain HTTP and SSL connections, another problem uncovered by Kolsek. And Internet Explorer (and possibly other browsers as well) would divulge previously entered passwords that were protected by SSL. Imagine that you have connected to a Web server using SSL, then entered your username and password into a dialogue box presented by your browser. The username and password are part of HTTP's Basic Authentication scheme, but were protected because the data exchange was encrypted by SSL. But if you were to later visit an area in the same site but without using SSL, your username and password would be sent unencrypted, potentially available to any eavesdroppers. Microsoft has published security advisories and patches that address both of these problems.
In October, Fu uncovered another interesting problem related to SSL and Akamai. Akamai provides support for high-speed and high-availabiltiy Web hosting. In a post to the BUGTRAQ mailing list, Fu reported that he had found that by proxying a request through an Akamai server to his own site (fooworld.org), the certifcate presented to your Web browser would be the one for the Akamai server, not the self-signed one at fooworld.org, and the Web user could easily be fooled into thinking they had reached a site with a valid certificate. Even better (or perhaps worse), someone could create a link to a valid appearing site (H0MEBANKING.COM, where the first 'O' is a zero), and the Web user could be fooled because the certificate would appear to be valid to the browser. This happened because Akamai's certificate was returned to the user, while the invalid or self-signed certificate was received by the Akamai proxy. Akamai fixed this problem by refusing to proxy for servers with these problems.
Some large sites deal with the slow pace of SSL key exchange by placing SSL proxy servers in front of their Web servers. This means that your precious secrets travel last few meters (or perhaps much further) unencrypted. And keep in mind that SSL does nothing to protect your data once it is stored at an e-commerce site. Your sensitive data may be stolen from improperly hardened sites.
While SSL does improve the security of electronic transactions over the Web, it is not a perfect solution. Weak encryption, accidental divulging of secrets like passwords or session cookies, cases of mistaken identity, combine to weaken the impression that SSL is a secure solution.
But SSL as it is used today has an even greater, and still unaddressed, weakness. SSL relies on Web browsers that have a pre-installed list of top level Certificate Authorities. You can view this list in Navigator by selecting Security/Certificates/ Signers. But what your browser does not do is check to see if any of these certificates has been revoked. If the owner of a certificate loses control of the private key associated with that certificate, the certificate can no longer be used, and must be revoked. But current browsers have no built-in mechanism for certificate revocation. Although incidents based on this scenario are rare, they do happen (see CA-2000.19).
The solution is not to toss out SSL, but rather to address the weaknesses in the ways it is currently used. And, as a Web user, to remember that seeing the closed padlock icon does not mean that your information is really secure, but that hopefully your data has been securely transported across the Internet to the correct server. Beyond that, there are no guarantees.
The draft of SSL v3: http://home.netscape.com/eng/ssl3/draft302.txt
The Secure HyperText Transfer Protocol: http://www.faqs.org/rfcs/rfc2660.html
An example of a self-signed certificate: https://snafu.fooworld.org/
Inconsistent Warning Messages in Netscape Navigator: http://www.cert.org/advisories/CA-2000-08.html
Netscape Navigator Improperly Validates SSL Sessions:
CERT Advisory CA-2000-05, May 12, 2000
http://www.cert.org/advisories/CA-2000-05.html
Kevin Fu's (MIT) report on a problem with Netscape, related to CA-2000-08: http://www.securityfocus.com/archive/1/62021
Mitja Kolsek, ACROS, Slovenia, describes how Web passwords may be stolen from IE: http://www.securityfocus.com/archive/1/139464
The MS patch for this:
http://www.microsoft.com/technet/security/bulletin/MS00-076.asp
Kolsek also reported problems with session cookies sharing: http://www.microsoft.com/technet/security/bulletin/fq00-080.asp
CERT advisory about the revocation of some of Sun Microsystem's certificates: http://www.cert.org/advisories/CA-2000-19.html