SSL and S-HTTP

Secure Communication over the Internet.

Most companies with connections to the Internet have implemented firewall solutions to protect the corporate network from unauthorized users coming inand unauthorized Internet sessions going outvia the Internet. But, while firewalls guard against intrusion and unauthorized use, they can guarantee neither the security of the link between a particular workstation and a particular server on opposite sides of a firewall nor the security of the actual message being conveyed.

To create this level of security, two related Internet protocols, Secure Sockets Layer (SSL) and Secure hypertext transfer protocol (S-HTTP), ensure that sensitive information passing through an Internet link is safe from prying eyes.

Secure Connection

SSL was developed by Netscape Communications (Mountain View, CA) for such instances as when sensitive, private information is sent from client to server through a TCP/IP connectionfor example, during an electronic commerce transaction. The protocol is application independent and operates at the Transport layer. This means application protocols such as HTTP, ftp, telnet, gopher, Network News Transport Protocol (NNTP), and Simple Mail Transport Protocol (SMTP) are easily and transparently layered on top of SSL, and TCP/IP is layered beneath it (see Figure 1).

Figure 1: SSL creates secure communications links across the Internet at a very basic level, making it possible for use in a variety of Internet sessions, including telnet, ftp, gopher, and SMTP.

When both a client (usually in the form of a Web browser) and a server support SSL, any data transmitted between the two becomes encrypted. Netscape Navigator and Microsoft's Internet Explorer both support SSL at the browser level, and Netscape's Commerce Server supports the protocol at the server level. Other Web servers that support SSL include SafetyWeb from CompuServe (Columbus, OH) and WebSite from Sebastopol, CA-based O'Reilly & Associates. When an SSL-compliant client wants to communicate with an SSL-compliant server, the client initiates a request to the server, which in turn sends an X.509 standard certificate back to the client. The certificate includes the server's public key and the server's preferred cryptographic algorithms, or ciphers.

The client then creates a key to be used for that session, encrypts the key with the public key sent by the server, and sends the newly created session key to the server. After it receives this key, the server authenticates itself by sending a message encrypted with the key back to the client, proving that the message is coming from the proper server. After this handshake process, which results in the client and server agreeing on the security level, all data transferred between that client and that server for a particular session (whether HTTP, telnet, ftp, and so on) is encrypted using the session key (see Figure 2).

Figure 2: SSL enabled sessions require server authorization, which consists of the server sending its public key to the client, which then generates a master key to be used to encrypt all communication for that particular session.

When using the Netscape Navigator browser, a user can tell that the session is encrypted by the key icon in the lower-left corner of the screen. When a session is encrypted, the key, which is usually broken, becomes whole, and the key's background becomes dark blue. Another way to detect a secure session is by the URL. When a secure link has been created, the first part of the URL at the top of the browser will change from http:// to https ://. The process I just described involves server authentication. In addition, a second phase, client authentication, may take place for extra security measures. SSL supports several cryptographic algorithms to handle the authentication and encryption routines. One algorithm, which was developed by RSA Data Security (now part of Security Dynamics), is RC4, a variable key- size cipher. Other cryptographic algorithms supported by SSL include Data Encryption Standard (DES), which works on 64-bit blocks of data with a 56-bit key, and triple-DES, which runs an encrypted message through DES three times.

Secure Messages

S-HTTP, as you might have guessed, is simply an extension of HTTP, the communications protocol of the World Wide Web. S-HTTP is created by SSL running under HTTP. The protocol was developed in 1994 by Enterprise Integration Technologies (EIT, Menlo Park, CA) as an implementation of the RSA encryption standard. While SSL operates at the Transport layer, S-HTTP supports secure end-to-end transactions by adding cryptography to messages at the Application layer, which means that while SSL is application independent, S-HTTP is tied to the HTTP protocol. Also, while SSL encrypts the entire communications link between a client and a server, S-HTTP encrypts each message on an individual basis.

S-HTTP, like SSL, can be used to provide electronic commerce without customers worrying about who might intercept their credit card number or other personal information. According to the Internet Engineering Task Force's (IETF's) latest S-HTTP Internet draft, an S-HTTP message consists of three parts : the HTTP message, the sender's cryptographic preferences, and the receiver's preferences. The sender integrates both preferences, which results in a list of cryptographic enhancements to be applied to the message.

To decrypt an S-HTTP message, the recipient must look at the message headers, which designate which cryptographic methods were used to encrypt the message. Then, to decrypt the message, the recipient uses a combination of his or her previously stated and current cryptographic preferences and the sender's previously stated cryptographic preferences.

S-HTTP doesn't require that the client possess a public key certificate, which means secure transactions can take place at any time without individuals needing to provide a key (as in session encryption with SSL).

An S-HTTP message includes a request line or status line and style headers, all of which precede the message's content. According to the IETF draft for version 1.2 of S-HTTP, all S-HTTP requests should include a request line that looks like this:

 Secure*Secure-HTTP/1.2 

This request line distinguishes an S-HTTP request from existing HTTP implementations . Servers should respond to this request with:

 Secure-HTTP/1.2 200 OK 

regardless of whether the request succeeded or failed.

An S-HTTP message header consists of several pieces of information, including Content-Type and Content-Privacy-Domain. An optional component outlined in the IETF draft is something called a Prearranged Key- Info header, which allows the use of session keys for return encryption when one party doesn't have a public and private key pair. However, it can also be used when both parties choose another method of encryption in place of the public and private key pair method, such as a one-time key.

The Prearranged Key-Info specification defines three ways to exchange keys: Kerberos, Inband, and Outband. Kerberos and Inband show that the session key has already been exchanged prior to the current communication. In the case of Kerberos, this can be accomplished through access to a trusted Kerberos server. Outband indicates that the sending and receiving parties have external access to keys through a database or other means. This part of the message header should look like this:

 Prearranged-Key-Info: <Hdr- Cipher>','<CoveredDEK>','   <CoverKey-ID>   <CoverKey-ID> := <method>':'   <key-name> <CoveredDEK> :=<hex-digits>   <method> :='inband' 'krb-' <kv> 'outband'   <kv> :='4'  '5' 

In this example, the <Hdr-Cipher> field should be filled with the name of the cipher used to encrypt the session key. This cipher could be DES, triple DES, IDEA (International Data Encryption Algorithm), or RC2. IDEA is a block cipher similar to DES, but with a larger key; RC2 is a variable key-size block cipher that encrypts blocks of 64 bits.

<CoveredDEK> is the Data Encryption Key, which is the key under which the message was encrypted. The draft specifies that this key should be randomly generated by the sender and then encrypted by the session key using the header cipher.

Calling A Truce

Not surprisingly, when Netscape announced SSI, and EIT announced S-HTTP, the industry and users quickly divided into two camps. Thankfully, vendors have woken up and realize the two protocols don't have to compete . Rather, the two can complement one another very well because SSL secures an Internet connection while S-HTTP secures HTTP-based messages.

Terisa Systems (Menlo Park, CA), an Internet security company formed by RSA Data Security and EIT, shipped the first security toolkits, which developers can use to build a Web server that supports both SSL and S-HTTP. The SecureWeb Client Toolkit 2.0 and Server Toolkit 2.0 allow companies to build secure Web servers for such applications as electronic commerce and other applications requiring the exchange of sensitive information. The products support RSA public key cryptography, as well as other cryptographic methods.

In the past year, two major credit card companies have teamed with the likes of Netscape, RSA Data Security, and Microsoft to provide yet another protocol to deliver secure commerce over the Internet. Secure Encryption Transaction (SET) is being supported by MasterCard and Visa as a means for customers to conduct electronic payment transactions.

While one can safely transmit credit card information through an SSL-encrypted session or within an S-HTTP message, SET differs from these two protocols by proposing to supply users with an X.509 digital certificate once their credit card numbers are authorized. The certificate would be attached to a user's browser and then used for all future purchases.

Technically, however, SET can work with both S-HTTP and SSL. And, with cooperation among the various companies to bring secure electronic transactions to the masses, final standards shouldn't be too far away.

Resources

For more information on Secure Sockets Layer, including a link to the most recent IETF Internet draft, access Netscape's Web site at http://www.netscape.com/newsref/std/SSL.html.

To view the latest S-HTTP Internet draft from the Internet Engineering Task Force, access ftp://www.ietf.org/internet-drafts/draft-ietf-wts-shttp-03.txt.

This tutorial, number 101, by Anita Karv, was originally published in the January 1997 issue of LAN Magazine/Network Magazine.