[an error occurred while processing this directive]

HP OpenVMS Systems

Secure Web Server (based on Apache™)
Content starts here

C O N T E N T S


HP Secure Web Server Documentation

SSL User Guide

Setup and Release Notes

Introduction to SSL

  • An SSL Primer

    Using mod_ssl Directives

    Understanding Certificates

    Using the Certificate Tool

    Using Certificates

    Glossary

    SSL Resource Guide

  • Chapter 3:

    An SSL Primer

    This chapter gives you a broad overview of the SSL technology and its application.

    __Topics_________________________

    The SSL Protocol

    The SSL Handshake

    What is public key encryption?

    The secure link

    How do certificates work?

    How to view browser certificates

    How does SSL use ciphers?

    How do digital signatures work?

    What are certificate chains?

     

    The SSL Protocol

    The SSL protocol works cooperatively with several other protocols. The underlying mechanism is TCP/IP (Transmission Control Protocol/Internet Protocol), which governs the transport and routing of data over the Internet. Application protocols, such as HTTP (HyperText Transport Protocol), LDAP (Lightweight Directory Access Protocol), and IMAP (Internet Messaging Access Protocol), run above TCP/IP. They use TCP/IP to support typical application tasks such as displaying web pages or running email servers.

    protocols

    The SSL protocol runs above TCP/IP and below HTTP, LDAP, and IMAP. It uses TCP/IP on behalf of these high-level protocols.

    SSL addresses three fundamental security concerns about communication over the Internet and other TCP/IP networks:

    • SSL server authentication allows a user to confirm a server's identity. SSL-enabled client software can use standard techniques of public-key cryptography to check that a server's certificate and public ID are valid and have been issued by a certificate authority (CA) listed in the client's list of trusted CAs. For example, if a PC user is sending a credit card number to make a purchase on the web and wants to check the receiving server's identity.

    • SSL client authentication allows a server to confirm a user's identity. Using the same techniques as those used for server authentication, SSL-enabled server software can check that a client's certificate and public ID are valid and have been issued by a certificate authority listed in the server's list of trusted CAs. For example, if a bank is sending confidential financial information to a customer and wants to check the recipient's identity.

    • An encrypted SSL connection requires all information sent between a client and a server to be encrypted by the sending software and decrypted by the receiving software, thus providing a high degree of confidentiality. Confidentiality is important for both parties to any private transaction. In addition, all data sent over an encrypted SSL connection is protected with a mechanism for detecting tampering - that is, for automatically determining if data has been altered in transit.

    The SSL Handshake

    An SSL session always begins with an exchange of messages called the SSL handshake. The handshake allows the server to authenticate itself to the client using public-key techniques, also called asymmetric encryption. It then allows the client and the server to cooperate in the creation of symmetric keys, which are used for rapid encryption, decryption, and tamper detection during the session that follows. Optionally, the handshake also allows the client to authenticate itself to the server.

    This exchange of messages is designed to facilitate the following actions:

    • Authenticate the server to the client.

    • Allow the client and server to select the cryptographic algorithms, or ciphers, that they both support.
    • Optionally authenticate the client to the server.
    • Use public-key encryption techniques to generate shared secrets.
    • Establish an encrypted SSL connection.

    WWW iPlanet: Introduction to SSL

    What is public key encryption?

    In traditional, non-Internet environments, encrypted information is sent between parties that both use the same key to encode and decode information. This is called symmetrical encryption. In the case of the Internet, there is no way for one computer to send the encryption key to another without the risk that a third party can steal the key and decode subsequent communications. A method other than symmetrical encryption is required to transmit the encryption key securely on the Internet.

    The principals of public key cryptography were developed by Whitfield Diffie and Martin Hellman. The Diffie-Hellman key agreement protocol was published in 1976. It is also called asymmetric encryption because it uses two keys instead of one key.

    The solution is a system that uses two keys. The first is a public key, and usually available to anyone who wants it. The second, a private key, is held by just one party. Only the private key can decipher information encrypted using the public key; it is impossible to decipher the message using the public key. Similarly, only the private key can create encrypted messages decipherable with the public key. Because there can be only one public key for each private key, and vice-versa, it is nearly impossible to impersonate the holder of the private key. The two keys are mathematically related, but in such a way that it is virtually impossible to derive the private key from the public one.

    During the SSL handshake, each computer generates a set of codes to encrypt information. From these codes, each computer creates two keys, one private and one public. Your computer keeps the private key secret, but sends out the public key to the other computer, which uses that key to encode subsequent messages so that only your computer can read them. The public key cannot, however, be used to decode the message; the decoding can only be done using the private key.

    These keys allow you and the other computer to lock and unlock information so that only the holder of the private key can read messages encrypted by the public key. Since only you and the other computer have a copy of your respective private keys, there is no way for anybody else to intercept and decode your messages.

    WWW Webopedia Definition and Links

    The secure link

    When a user enters a secure link to send information with either Netscape Communicator or Microsoft Internet Explorer, the browser negotiates the key code exchanges so the user is not aware of this happening. However, the page information downloads more slowly on the secure link than it does on unsecured links because of the extra encryption information being sent. Both the user's computer and the server computer generate a public-private key set, and then exchange public keys with each other.

    Once this exchange has occurred, a new master key is generated and transmitted through the secure connection. This master key is symmetrical; messages can now be both encrypted and decrypted using the same key. In addition, a message authentication code (MAC) is used to make sure that the information being exchanged is not altered during transmission.

    How do certificates work?

    A certificate, or digital certificate, is an electronic document used to identify an individual, a server, a company, or some other entity and to associate that identity with a public key. Like a driver's license, a passport, or other commonly used personal IDs, a certificate provides generally recognized proof of a person's identity. Public-key cryptography uses certificates to address the problem of impersonation.

    Certificates are issued by certificate authorities (also known as certification authorities). These are trusted third parties that verify the identity of the site you are connected with. Like any form of identification, the authenticity of the issuer is essential.

    The role of CAs in validating identities and issuing certificates is analogous to the way a government issues passports and driver's licenses. CAs can be either independent third parties or organizations running their own certificate-issuing server software (such as Netscape Certificate Server).

    The methods used to validate an identity vary depending on the policies of a given CA. In general, before issuing a certificate, the CA must use its published verification procedures for that type of certificate to ensure that an entity requesting a certificate is in fact who it claims to be.

    The certificate issued by the CA binds a particular public key to the name of the entity the certificate identifies (such as the name of an employee or a server). Certificates help prevent the use of fake public keys for impersonation. Only the public key certified by the certificate will work with the corresponding private key possessed by the entity identified by the certificate.

    In addition to a public key, a certificate always includes the name of the entity it identifies, an expiration date, the name of the CA that issued the certificate, a serial number, and other information. Most importantly, a certificate always includes the digital signature of the issuing CA. The CA's digital signature allows the certificate to function as a "letter of introduction" for users who know and trust the CA but don't know the entity identified by the certificate.

    WWW IPlanet: Introduction to Public-Key Cryptography

    How to view browser certificates

    Netscape and Microsoft browsers have built-in lists of CAs, which you can choose to alter. There is no absolute list of which certificate authorities are reliable, but the ones included in Netscape and Microsoft browsers have been accepted as dependable by Netscape and Microsoft. If you connect with a secure site authorized by a CA not listed in your browser's list, you will be alerted and asked if you want to add the new CA to your browser's list. You should not add a new CA to your list unless you have a good reason to trust the CA.

    Viewing certificates in Microsoft Internet Explorer
    To view CA certificates that are contained in the browser's Certificate Manager:

    1. On the Tools menu in Internet Explorer, click Internet Options.

    2. Click the Content tab.
    3. In the Certificatesarea, click the Certificates button to view the list of current certificates by category, including Trusted Root Certification Authorities.

    Viewing certificates in Netscape Navigator
    To view the CA certificates that are contained in the browser's Trusted Root Library:

    1. On the Netscape toolbar, click the Security icon to open the Security Info window.

    2. Click the link labeled Signers to open the Certificate Signers' Certificates window, containing a list of all the CA certificates contained in the browser.

    In addition, you can view the specific certificate being used in a secure connection by double-clicking on the padlock symbol in your browser's status bar.

    How does SSL use ciphers?

    Integral to the SSL protocol is its use of cryptographic algorithms, generally called ciphers. These are required to authenticate the server and client to each other, transmit certificates, and establish session keys. Clients and servers may support different cipher suites, or sets of ciphers, depending on factors such as the version of SSL they support, company policies regarding acceptable encryption strength, and government restrictions on export of SSL-enabled software.

    Among its other functions, the SSL handshake protocol determines how the server and client negotiate which cipher suites they will use to authenticate each other, to transmit certificates, and to establish session keys. Key-exchange algorithms like KEA and RSA key exchange govern the way in which the server and client determine the symmetric keys they will both use during an SSL session. The most commonly used SSL cipher suites use RSA key exchange.

    The SSL 2.0 and SSL 3.0 protocols support overlapping sets of cipher suites. Administrators can enable or disable any of the supported cipher suites for both clients and servers. When a particular client and server exchange information during the SSL handshake, they identify the strongest enabled cipher suites they have in common and use those for the SSL session.

    Decisions about which cipher suites a particular organization decides to enable depend on trade-offs among the sensitivity of the data involved, the speed of the cipher, and the applicability of export rules.

    WWW Cipher Suite with RSA Key Exchange

     iPlanet e-Commerce Solutions

    FORTEZZA Cipher Suites

    How do digital signatures work?

    Encryption and decryption address the problem of eavesdropping. However, tampering and impersonation are still possible.

    Public-key cryptography addresses the problem of tampering using a mathematical function called a one-way hash (also called a message digest). A one-way hash is a fixed-length number whose value is unique to the data being hashed. Any change in the data, even deleting or altering a single character, results in a different value.

    The content of the hashed data cannot, for all practical purposes, be deduced from the hash, which is why it is called "one-way."

    This principle is the crucial part of digitally signing any data. Instead of encrypting the data itself, the signing software creates a one-way hash of the data, then uses your private key to encrypt the hash. The encrypted hash, along with other information, such as the hashing algorithm, is known as a digital signature.

     

    What are certificate chains?

    The X.509 standard (the certificate protocol used by SSL) includes a model for setting up a hierarchy of CAs, making it possible to delegate certificate-issuing responsibilities to subordinate CAs. Inspecting a browser's certificate store will show a collection of "intermediate CAs."

    CA hierarchies are reflected in certificate chains. A certificate chain is a succession of certificates issued by successive CAs. Trusted root CAs are at the pinnacle of the pyramid and are the only entities to self-sign their certificates.

    Using the mod_ssl directive SSLVerifyDepth you can determine how many levels of intermediate CAs you would like your server to authenticate.

    SSLVerifyDepth directive