SSL is 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 it is intercepted in route. Clients receiving data from the server then decrypt the ciphertext in order to read the data. The use of 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.
For a server and client to use SSL for secure communications, the server must have a public-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 that they can verify that the signed messages are actually from the server and so that they can encrypt messages to the server, which the server decrypts with its private key.
To send its public key to clients, the server needs a certificate issued by a certification authority (CA). The certificate contains the server's public key, the Distinguished Name associated with the server's certificate, the serial number or issue date of the certificate, and the expiration date of the certificate.
A certification 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; its public key can be used to ensure that the certificate is valid. A signed certificate binds the server's identity to a pair of electronic keys that can be used to encrypt and sign digital information. The certificate itself is signed with the certification authority's private key to verify that the server is who it says it is.
To operate a Web server in secure SSL mode, you must first obtain a signed certificate for your system from a certification authority. VeriSign, Inc. is one of a number of companies that acts as a certification authority. However, you can use a signed certificate of the appropriate format from any certification authority.
When you set up secure connections, your public key must be associated with a digitally signed certificate from a certificate authority (CA) who is designated as a trusted CA on your server.
Getting started with secure connections
To learn more about certificates - http://digitalid.verisign.com/
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 to be protected.
A secure network communication has the following characteristics:
Resources can be protected and accessed only by authorized parties. Restricting access on the basis of passwords, IP address, host names, or SSL client authentication ensures access control.
You know who you are talking to and that you can trust that person. Authentication, using digital signature and digital certificates, ensures authenticity.
Messages are not altered while being transmitted. Without information integrity, you have no guarantee that the message you sent matches the message received. Digital signature ensures integrity.
Information conveyed from party to party during a transaction remains private and cannot be read even if it gets into the wrong hands. Encryption ensures privacy and confidentiality.
Encryption in its simplest form is scrambling a message so that it cannot be read until it is unscrambled later 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.
There are two kinds of keys that can be used for encryption:
With asymmetric keys, you create a key pair. The key pair is made up of a public key and a private key, which are different from each other. The private key holds more of the secret encryption pattern than the public key. Your private key should not be shared 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 that has been encrypted with your public key, because only you have the private key. Key pairs are stored in a key database which is protected by a password.
Symmetric keys follow an age-old model of the sender and receiver sharing some kind of pattern. This same pattern is then used by the sender to encrypt the message and by the receiver to decrypt the message.
The risk involved with symmetric keys is that you have to find a safe transportation method to use when sharing your secret key with the people you want to communicate with.
The Secure Sockets Layer (SSL) protocol uses both asymmetric and symmetric key exchange. Asymmetric keys are used for the SSL handshake. During the handshake the master key, encrypted with the receiver's public key, is passed from the client to the server. The client and server make their own session keys using the master key. The session keys are used to encrypt and decrypt data for the remainder of the session. Symmetric key exchange is used during the exchange of the cipher specification (or encryption level) used.
To send its public key to clients, the server needs a digital certificate. This certificate is issued by a certificate authority (CA) who verifies the identity of the server.
Related Information:
Authentication is the process used to verify identity, so that you can ensure that others are who they say they are. There are two ways that the server uses authentication:
A digital signature is a unique mathematically computed signature that ensures accountability. A digital signature is similar to a credit card with your picture on it. To verify the identity of the person sending you a message, you look at the sender's digital certificate.
A digital certificate (or digital ID), is like 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 for the authenticity of the sender on whether you trust the third party (a person or agency) that certified the sender. The third party who issues digital certificates is called a certificate authority (CA) or certificate signer.
A digital certificate contains:
You enter your Distinguished Name as part of requesting a certificate. The digitally-signed certificate includes not only your own Distinguished Name but the Distinguished Name of the CA.
You can request one of the following certificates:
CAs broadcast their public key and Distinguished Name bundled together so that people will 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 be a trusted CA certificate, this means that 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 as needed using the IBM Key Management Utility included with your server.
In order to communicate securely, the receiver in a transmission must trust the CA who issued the sender's certificate. This is 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.
Related Information:
A Public Key Infrastructure (PKI) is a system of digital certificates, certificate authorities, registration authorities, certificate management service, and X.500 directories that verify the identity and authority of each party involved in any transaction over the Internet. These transactions may be financial or may involve any operation where identity verification is required, such as confirming the origin of proposal bids or author of e-mail messages.
A PKI supports the use of certificate revocation lists (CRLs). A certificate revocation list is a list of certificates that have been revoked. CRLs provide a more global method for authenticating a client's identity by certificate, and can also be used to verify the validity of trusted CA certificates.
CRLs and trusted CA certificates are stored and retrieved from an X.500 directory server. The protocols used for storing and retrieving information from an X.500 directory server are Directory Access Protocol (DAP) and Lightweight Directory Access Protocol (LDAP). The HTTP Server supports LDAP.
Information can be distributed on multiple directory servers over the Internet and intranets, thus allowing an organization to manage certificates, trust policy, and CRLs from either a central location or in a distributed manner. This makes the trust policy more dynamic because trusted CAs can be added or deleted from a network of secure servers without having to reconfigure each of the servers.
Related Information:
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. It allows the client to authenticate the identity of the server. SSL Version 3 is required to authenticate the identity of a client.
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 will not be able to request URLs using HTTPS. The non-SSL browsers will not allow submission of forms that need to be submitted securely.
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 they will use for the session and the algorithms they will use for encryption. The client authenticates the server; optionally, the server can request the client's certificate. After the handshake, SSL is used to encrypt and decrypt all of the information in both the https request and the server response, including:
HTTPS is a unique protocol that combines SSL and HTTP. You need to 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 at the same time. As a result, you can choose to provide information to all users using no security, and specific information only to browsers who make secure requests. This is how a retail company on the Internet can allow users to look through the merchandise without security, but then fill out order forms and send their credit card numbers using security.
Related Information: