Using the Secure Sockets Layer protocol for secure communications
This section provides foundation information for the Secure Sockets Layer (SSL) protocol, including a general overview of the protocol, and explanations of security concepts. Links to related topics appear at the end of this section.
SSL represents an encryption system used on servers to ensure privacy when transmitting information across the World Wide Web. SSL-enabled servers encrypt sensitive data into ciphertext before sending it to clients, preventing third parties from reading the data, even if they intercept this data en route. Clients receiving data from the server then decrypt the ciphertext to read the data. Using SSL on a Web server helps ensure that information transmitted between a client, such as a Web browser and a server, such as a Web server, remains private, and enables the clients to authenticate the identity of the server.
Using SSL for secure communications
For a server and client to use SSL for secure communications, the server must have a public and private key pair and a certificate. The server uses its private key to sign messages to clients. The server sends its public key to clients so these clients can verify that the signed messages come from the server and so they can encrypt messages to the server. The server then decrypts these messages with its private key.
To send its public key to clients, the server needs a certificate issued by a certificate authority (CA). The certificate contains a server public key, the distinguished name associated with the server certificate, the serial number or issue date of the certificate, and the expiration date of the certificate.
A certificate authority (CA) is a trusted third party (or a designated internal authority) that issues certificates. The CA verifies the identity of the server and digitally signs the certificate with its private key and uses its public key to ensure that the certificate is valid. A signed certificate binds server identity to a pair of electronic keys, used to encrypt and sign digital information. The certificate authority private key signs the certificate to verify server identity.
To operate a Web server in secure SSL mode, you must first obtain a signed certificate for your system, from a certificate authority. VeriSign, Inc. represents one of a number of companies that acts as a certificate authority. However, you can use a signed certificate of the appropriate format from any certification authority.
When you set up secure connections, associate your public key with a digitally signed certificate from a certificate authority (CA), designated as a trusted CA on your server.
Reviewing security concepts
This section provides an overview of security concepts.
The rapid growth of electronic commerce over the Internet has led to an increasing demand for secure network communications. In addition, intra-company communications over private networks often contain confidential information that needs protection.
A secure network communication has the following characteristics:
Encryption in its simplest form involves scrambling a message so that no one can read the message until unscrambled by the receiver. The sender uses an algorithmic pattern, or key to scramble, or encrypt the message. The receiver has the decryption key. Encryption ensures privacy and confidentiality in transmissions sent over the Internet.
Use two different kinds of keys for encryption:
The Secure Sockets Layer (SSL) protocol uses both asymmetric and symmetric key exchange. Use asymmetric keys for the SSL handshake. During the handshake, the master key, encrypted with the receiver public passes from the client to the server. The client and server make their own session keys using the master key. The session keys encrypt and decrypt data for the remainder of the session. Symmetric key exchange occurs during the exchange of the cipher specification, or encryption level.
The server needs a digital certificate to send its public key to clients. A certificate authority (CA) issues this certificate and verifies the identity of the server.
Authentication verifies identity. The server uses authentication in two ways:
CAs broadcast their public key and distinguished name bundled together so that people add them to their Web servers and browsers, as a trusted CA certificate. When you designate the public key and certificate from a CA to become a trusted CA certificate, your server trusts anyone who has a certificate from that CA. You can have many trusted CAs as part of your server. The HTTP Server includes several default trusted CA certificates. You can add, or remove trusted CAs, using the IBM Key Management Utility included with your server.
To communicate securely, the receiver in a transmission must trust the CA who issued the sender certificate. This situation remains true whether the receiver is a Web server or browser. When a sender signs a message, the receiver must have the corresponding CA-signed certificate and public key designated as a trusted CA certificate.
Identifying a Public Key Infrastructure
A Public Key Infrastructure (PKI) represents a system of digital certificates, certificate authorities, registration authorities, certificate management service, and X.500 directories. PKI verifies the identity and authority of each party involved in an Internet transaction, either financial, or operational with requirements for identity verification. Examples of these transactions include confirming the origin of proposal bids, or the author of e-mail messages.
A PKI supports the use of certificate revocation lists (CRLs). A CRL is a list of revoked certificates. CRLs provide a more global method for authenticating client identity by certificate, and can verify the validity of trusted CA certificates.
An X.500 directory server stores and retrieves CRLs and trusted CA certificates. The protocols used for storing and retrieving information from an X.500 directory server include Directory Access Protocol (DAP) and Lightweight Directory Access Protocol (LDAP). The IBM HTTP Server supports LDAP.
You can distribute information on multiple directory servers over the Internet and intranets, enabling an organization to manage certificates, trust policy, and CRLs from either a central location, or in a distributed manner. This capability makes the trust policy more dynamic because you can add or delete trusted CAs from a network of secure servers, without having to reconfigure each of the servers.
Looking at the Secure Sockets Layer protocol
The Secure Sockets Layer (SSL) protocol was developed by Netscape Communications Corporation. SSL ensures that data transferred between a client and a server remains private. This protocol enables the client to authenticate the identity of the server. SSL Version 3, requires authentication of the client identity.
Once your server has a digital certificate, SSL-enabled browsers like Netscape Navigator and Microsoft Internet Explorer can communicate securely with your server, using SSL. With SSL, you can easily establish a security-enabled Web site on the Internet, or on your private intranet. A browser that does not support HTTP over SSL cannot request URLs using HTTPS. The non-SSL browsers do not allow submission of forms that require secure communications.
SSL uses a security handshake to initiate a secure connection between the client and the server. During the handshake, the client and server agree on the security keys to use for the session and the algorithms to use for encryption. The client authenticates the server; optionally, the server can request the client certificate. After the handshake, SSL encrypts and decrypts all the information in both the HTTPS request and the server response, including:
HTTPS represents a unique protocol that combines SSL and HTTP. Specify https:// as an anchor in HTML documents that link to SSL-protected documents. A client user can also open a URL by specifying https:// to request an SSL-protected document.
Because HTTPS (HTTP + SSL) and HTTP are different protocols and use different ports (443 and 80, respectively), you can run both SSL and non-SSL requests simultaneously. This capability enables you to provide information to users without security, while providing specific information only to browsers making secure requests. This functionality enables a retail company on the Internet to allow users to look through their merchandise without security, but then fill out order forms and send their credit card numbers using security.
(Back to the top)