SSL is a protocol that was originally defined by Netscape Communications Corporation to allow two machines communicating over TCP/IP to encrypt the information sent between them. After a communication session is secured in this way, the two machines can exchange private or sensitive information without worrying about eavesdroppers or other interlopers stealing or using the information. This is an essential feature for Web servers used for e-commerce because they often require the transfer of personal, confidential information such as credit card numbers or account codes.
Public-Private Key Systems
To encrypt the packets that travel between two machines, the machines must understand a common encryption algorithm and must exchange some information that allows one machine to decrypt (unscramble) what the other one encrypts. The parts of the security information that are used to encrypt or decrypt data are called keys.
Encryption is performed by making a modification to the information at one location, using a key. The information is then transmitted to another location, where a key is used to restore the information to its original form (decrypt it). In a simple system, the key used to encrypt the information is the same key that is used to decrypt it. This is called a private key system because the contents of the key must be kept secret for the information to be kept secret. However, private key systems present a problem because the key must be somehow transmitted securely to the new location. SSL uses a special kind of encryption, called a public-private key system, as a part of the overall system that it uses to allow secure communications sessions.
A discussion of the mathematical details of public-private keys is outside the scope of this short section. However, in such a key system, two keys are used for the encryption/decryption process, and one of them (called the public key) can be made freely available to anyone without damaging the security of the communications between the two machines. This solves the problem of secure key distribution inherent in private key systems.
Certificates: Verifying Who Is at the Other End of a Secure Session
Another issue that is related to secure communications is whether to trust the Web server with which you are communicating. Although a Web server might send a client a key so that the server can communicate securely with the client, it is possible that the client might be talking to the wrong Web server (for example, the server might provide a credit card number to some fake server run by con artists). When a public-private key system is used, it is also possible to transmit some additional information, called a certificate, which describes the Web server and the organization behind it.
This certificate can be electronically "signed" by a trusted agency. Various agencies research both the organization that is running the Web site and the information in the certificate. These agencies then sign the certificatefor a price. Client browsers use a list of trusted agencies to verify the signature on a certificate. The use of a signed certificate allows a client to verify that it is communicating with the server that the user intends it to (that is, it verifies that the server is actually run by the organization that the user expects).
When you set up a secure Web server, you must create a public-private key pair and a certificate for use with the server. If you want to run a secure Web site for public use, you must also get your certificate signed by one of these trusted agencies.
Use of Secure HTTP: HTTPS
When communicating with a secure Web server, the client uses a different protocol, called Secure HTTP (HTTPS), instead of HTTP. As the name implies, HTTPS is similar to HTTP, but with security added to it.
To access a secure Web server, a user must specify the URL with the https protocol identifier, as follows:
One of the most common mistakes that new administrators of secure Web servers make is failing to use the correct protocol type (HTTPS) in URLs that refer to the secure Web site. Whereas the default TCP port for the HTTP protocol is port 80, the default port for HTTPS is 443. When a browser tries to access a secure server at the wrong port, the browser appears to hang and eventually times out.
This can be disconcerting to end users, so take special care to test all the URLs that you create and that link to your secure site.