Using the Secure Sockets Layer protocol for secure communications: IBM HTTP Server 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. Using SSL for secure communications Reviewing security concepts Communicating securely Understanding encryption Understanding authentication Identifying a Public Key Infrastructure Looking at the Secure Sockets Layer protocol Finding related information 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. Communicating securely 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: Access control Only authorized parties protect and access resources. Restricting access on the basis of passwords, IP address, host names, or SSL client authentication ensures access control. Authenticity You know who you are talking to and that you can trust that person. Authentication, using digital signature and digital certificates, ensures authenticity. Information integrity Messages do not get altered during transmission. Without information integrity, you have no guarantee that the message you sent matches the message received. Digital signature ensures integrity. Privacy and confidentiality Information conveyed from party to party during a transaction remains private and confidential, even if it gets into the wrong hands. Encryption ensures privacy and confidentiality. Understanding encryption 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: Asymmetric keys You create a key pair with asymmetric keys. The key pair consists of a public key and a private key, which differ from each other. The private key holds more of the secret encryption pattern than the public key. Do not share your private key with anyone. The server uses its private key to sign messages to clients. The server sends its public key to clients so that they can encrypt messages to the server, which the server decrypts with its private key. Only you can decrypt a message encrypted with your public key because only you have the private key. Key pairs are stored in a key database protected by a password. Symmetric keys Symmetric keys follow an older model of the sender and receiver sharing some kind of pattern. The sender uses this same pattern to encrypt the message and the receiver uses this pattern to decrypt the message. The risk involved with symmetric keys centers around finding a safe transportation method to use, when sharing your secret key with the people to which you want to communicate. 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. Understanding authentication Authentication verifies identity. The server uses authentication in two ways: Digital signature A digital signature represents a unique mathematically computed signature that ensures accountability. Think of a digital signature as similar to a credit card, on which your photo displays. To verify the identity of the person sending you a message, look at the digital certificate of the sender. Digital certificate A digital certificate, or digital ID, is similar to having a credit card with a picture of the bank president with his arm around you. A merchant trusts you more because not only do you look like the picture on the credit card, the bank president trusts you, too. You base your trust of the sender authenticity on whether you trust the third party, a person, or agency that certified the sender. The third party issuing digital certificates is called a certificate authority (CA) or certificate signer. A digital certificate contains: The public key of the person getting certified The name and address of the person or organization getting certified, also known as the distinguished name The digital signature of the CA The issue date The expiration date You enter your distinguished name as part of a certificate request. The digitally signed certificate includes your distinguished name and the distinguished name of the CA. You can request one of the following certificates: A server certificate to do commercial business on the Internet from VeriSign or some other CA. For a list of supported CAs, see Buying a certificate from an external CA provider. A server certificate that you create for your own private Web network. 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: The URL requested by the client The contents of any submitted form Access authorization information, like user names and passwords All data sent between the client and the server 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. Finding related information Authenticating Secure Sockets Layer clients and Secure Sockets Layer Version 3 Getting started quickly with secure connections Associating your public key with certificate authorities Linking to Security Web site Locating glossary terms Retrieving Lightweight Directory Access Protocol information Using certificates Using cipher specifications and key sizes
(Back to the top)
