July 1996

Netscape Communications Corporation

Taher Elgamal, Chief Scientist
Jeff Treuhaft, Director of Security Products
Frank Chen, Product Manager, Security


Providing robust security services is chief among the challenges faced by information systems teams that are building full-service intranets or connecting to the public Internet. IS teams want to provide such services as single-user login, message privacy, and access control for safeguarding confidential documents. These services need to be provided in a cross-platform (Windows, Macintosh, Unix, etc.) and application independent (Web server, Web client, mail server, news servers, directory server, proxy server, etc.) way.

Fortunately, industry-standard solutions to these challenges are emerging. Cryptography plays a pivotal role in these standard solutions. This technology white paper discusses the motivations, protocols, and Netscape product offerings for deploying cryptographic technology throughout the enterprise and over the public Internet.

This paper covers the following topics:

Security challenges and solutions
Typical security challenges
Cryptographic technology
Secure Sockets Layer (SSL)
Security features in Netscape products
Netscape Navigator
Netscape SuiteSpot
Future directions for Netscape products
Deploying Netscape products for secure communications and collaboration
Building versus outsourcing a certificate infrastructure
Safeguarding real-time communications
Enabling single-user login
Deploying secure email
Scaling to the public Internet


There are many challenges in building a full-service intranet that provides safe communications and collaboration. As the exponential growth of the public Internet demonstrates, TCP/IP solves many problems in a remarkably scalable way. However, TCP/IP was not designed to offer secure communication services.

Because TCP/IP was not designed with security in mind, we must bring additional technology and policies to bear to solve typical security problems such as the following:

Remarkably, there is a single technology that provides the foundation for solving all of these challenges: cryptography. Cryptographic technology is embodied in industry-standard protocols such as SSL (Secure Sockets Layer), SET (Secure Electronic Transactions) and S/MIME (Secure Multipart Internet Mail Encoding). These standards provide the foundation for a wide variety of security services, including encryption, message integrity verification, authentication, and digital signatures. In the next section, we provide a quick overview of cryptography as well as references for further reading.

Cryptography is a surprisingly general technology that provides the foundation for each of the security challenges listed above. The next sections describe how public-key technology works and explains its role in industry-standard protocols such as SSL and S/MIME.

What Is Cryptography?
Cryptography comprises a family of technologies that include the following:

All of these technologies make use of sophisticated mathematical techniques. For more information on cryptography, please see RSA's Frequently Asked Questions.

Symmetric-Key and Public-Key Cryptography
Symmetric-key or secret-key cryptography uses the same key to encrypt and decrypt messages. This is a familiar real-world phenomenon: We use the same key to unlock and lock our car doors, for instance. The problem with symmetric-key cryptography is having the sender and receiver agree on a secret key without anyone else finding out. How can they do this? Over the phone, on a floppy disk, using a courier? All of these are cumbersome, slow, and error-prone techniques. In addition, the number of Keys tends to be much larger than the number of nodes; that is, people may have multiple keys they use for different purposes.

Public-key cryptography was invented in 1976 by Whitfield Diffie and Martin Hellman to solve precisely this problem. With public-key cryptography, each person gets a pair of keys, a public key and a private key. Each person's public key is published, while the private key is kept secret. When Alice wants to send Bob a secure message, she encrypts it using Bob's public key. When Bob gets the message, he decrypts it using his private key. The sender and receiver no longer have to share secret information before they can communicate securely.

In practice, both symmetric-key and public-key techniques are used in popular security protocols such as SSL and S/MIME because symmetric-key algorithms tend to be much faster than public-key algorithms. Let's visit Alice and Bob again. They want to communicate securely, but they also want to communicate quickly. Here's what they do:

  1. Alice generates a random number (key) that will be used for actually encrypting her message to Bob.

  2. Alice encrypts the random number with Bob's public key.

  3. Bob decrypts the random number with his private key. Now Bob has a secret shared with only Alice that they can use to encrypt and decrypt messages to each other.

In reality, most security protocols are much more complicated than this, but the three-step process above gives you an idea of the fundamentals. SSL is an excellent example of a security protocol that uses these techniques to safeguard communications. See our description of how SSL uses symmetric-key and public-key encryption.

Public-Key Certificates
Digital certificates, also called digital IDs, digital passports, or public-key certificates, are defined by an ITU standard called X.509. A certificate is the digital equivalent of an employee badge, passport, or driver's license.

The certificate and corresponding private key identify you to someone who needs proof of your identity. If you are pulled over by the highway patrol, you need to show your driver's license to prove that you are legally licensed to drive a car. If you want to get into a secure workplace, you might have to show a badge to prove that you are an employee of the company. If you want to make a credit card purchase, you typically have to show a credit card and demonstrate that you can produce a signature like the one on the back of your card. All of these forms of identification allow you to establish your identity with someone.

Over a network, a certificate serves the same role as a driver's license, employee badge, or credit card: It establishes your identity. Servers may be configured to grant access only to people with particular certificates; similarly, clients may be configured to trust servers that present certain certificates.

What's in a Certificate? An X.509 certificate is typically a small file that contains the information shown in the following table.

Field Description Examples
Subject's distinguished name (DN) A name uniquely identifying the owner of the certificate C=US, O=Netscape Communications, OU=Technology, CN=Marc Andreessen
Issuer's distinguished name (DN) A name uniquely identifying the certificate authority that signed the certificate C=US, O=VeriSign, CN=VeriSign Class 1 root
Subject's public key The owner's public key 512-bit RSA key
Issuer's signature The certificate authority's digital signature from which the certificate derives its authenticity RSA encryption with MD5 hash (signature itself is not human readable)
Validity period Dates between which the certificate is valid Not before
Wed, Nov 9, 1995, 15:54:17
Not after
Fri, Dec 31, 1997, 15:54:17
Serial number A unique number generated by the certificate authority for administrative purposes 02:41:00:00:01

With this overview of public-key technology in mind, let us review the challenges described at the beginning of this paper and see how public-key technology embodied in industry-standard protocols such as SSL and S/MIME offers solutions for those challenges.

Requirement Public-Key Technology Example of Typical Use
Authentication of users without username and password in the clear Digital certificates (X.509) SSL handshake includes exchange of client and server certificates and corresponding signatures.
Single-user login Digital certificates (X.509) Servers may be configured to demand digital certificates rather than username/password pairs.
Scalability to the Internet Standards-based encryption and message digest algorithms (for example, RSA, DES) negotiated using industry-standard protocols (for example, SSL) Unlike most proprietary security systems, SSL works both inside and outside the firewall.
Message privacy (real-time as well as store-and-forward applications) Public-key encryption and RSA decryption (for example, RSA). Often used in conjunction with symmetric-key technology (for example, RC2, RC4, and DES) for higher performance. SSL protects the session key used to encrypt and decrypt a data stream with public-key encryption. S/MIME uses a similar technique for encrypting and signing email messages in a store-and-forward paradigm.
Message integrity Message authentication codes calculated using message digest algorithms (MD5, SHA1) SSL calculates message authentication codes (MACs) using a message digest algorithm and a key negotiated during the SSL handshake.
Protection of confidential documents from unauthorized access Digital certificates (X.509) and signatures Binds users listed in access control lists (ACLs) to certificates or requires that users present a particular certificate (for example, signed by the Netscape Marketing Certificate Authority) for access.

Secure Sockets Layer (SSL) is an industry-standard protocol that makes substantial use of public-key technology. SSL is widely deployed on the intranet as well as over the public Internet in the form of SSL-capable servers and clients from leading vendors including Netscape, Microsoft, IBM, Spyglass, and Open Market as well as public-domain products such as Apache-SSL. All Netscape products - clients, servers, and applications - incorporate SSL to provide advanced security services. The features in each product are described in detail below.

SSL provides three fundamental security services, all of which use public-key techniques:

Service Underlying Technology Protection Against
Message privacy Encryption Eavesdroppers
Message integrity Message authentication codes (keyed hash functions) Vandals
Mutual authentication X.509 certificates Impostors

Message privacy. Message privacy is achieved through a combination of public-key and symmetric key encryption, as described above. All traffic between an SSL server and SSL client is encrypted using a key and an encryption algorithm negotiated during the SSL handshake described below. Encryption thwarts eavesdroppers who can capture a TCP/IP session using devices such as IP packet sniffers. Even though packet sniffers can still capture the traffic between a server and client, the encryption makes it impractical for them to actually read the message.

Message integrity. The message integrity service ensures that SSL session traffic does not change en route to its final destination. If the Internet is going to be a viable platform for electronic commerce, we must ensure that vandals do not tamper with message contents as they travel between clients and servers. SSL uses a combination of a shared secret and special mathematical functions called hash functions to provide the message integrity service.

Mutual authentication. Mutual authentication is the process whereby the server convinces the client of its identity and (optionally) the client convinces the server of its identity. These identities are coded in the form of public-key certificates, and the certificates are exchanged during the SSL handshake.

To demonstrate that the entity presenting the certificate is the legitimate certificate owner (rather than some impostor), SSL requires that the certificate presenter must digitally sign data exchanged during the handshake. The exchanged handshake data includes the entire certificate. The entities sign protocol data (which includes their certificates) to prove they are the legitimate owner of the certificate. This prevents someone from masquerading as you by presenting your certificate. The certificate itself does not authenticate; the combination of the certificate and the correct private key does.

What Happens During the SSL Handshake
SSL is designed to make its security services as transparent as possible to the end user. Typically, users click a link or a button on a page that connects to an SSL-capable server. A typical SSL-capable Web server accepts SSL connection requests on a different port (port 443 by default) than standard HTTP requests (port 80 by default).

When the client connects to this port, it initiates a handshake that establishes the SSL session. After the handshake finishes, communication is encrypted and message integrity checks are performed until the SSL session expires. SSL creates a session during which the handshake needs to happen only once. Performing an SSL handshake for every HTTP connection would result in poor performance.

The following high-level events take place during an SSL handshake:

  1. The client and server exchange X.509 certificates to prove their identity. This exchange may optionally include an entire certificate chain, up to some root certificate. Certificates are verified by checking validity dates and verifying that the certificate bears the signature of a trusted certificate authority.

  2. The client randomly generates a set of keys that will be used for encryption and calculating MACs. The keys are encrypted using the server's public key and securely communicated to the server. Separate keys are used for client to server and server to client communications for a total of four keys.

  3. A message encryption algorithm (for encryption) and hash function (for integrity) are negotiated. In Netscape's SSL implementation, the client presents a list of all the algorithms it supports, and the server selects the strongest cipher available. Server administrators may turn particular ciphers on and off.

SSL 2 Versus SSL 3
The first generations of Netscape products (including, for example, Netscape Navigator 2.0, Netscape Commerce Server 1.0, and Netscape News Server 1.0) implement SSL version 2.

The current generation of Netscape products (including Netscape Navigator 3.0 and the Netscape SuiteSpot server products) implement version 3 of the SSL protocol. The SSL 3 protocol incorporates feedback on SSL 2 from a wide variety of companies. The basic services SSL provides - message integrity, message privacy, and mutual authentication - are the same in both versions 2 and 3 of the protocol. However, SSL 3 boasts a number of protocol enhancements such as the following: