Posted by arlene

SSL is based on encrypting data between your browser and a Web server. There are other uses for SSL, but this is perhaps the most widespread use. There are two basic methods for encrypting data transactions on a network:

• Symmetric—A single key known by both sides of the communication is used to encrypt the data.
• Asymmetric—Two keys, called the public key and private key, are used to establish an encrypted data transfer.

When you’re using symmetric encryption, there is the problem of exchanging the single key so that both sides can use it to encrypt and decrypt the data. How do you send a secret key to the other party to a transaction? Use snail mail, place a telephone call, or send it as plain-text across the Internet? Obviously, none of these methods is truly secure. Sending the key via the postal service can take a few days or more, and using a telephone conversation for each Web server you want to contact can take more time than it would be worth. And, a plain-text transfer, like the previous two methods, is open to interception by a third party. Letters can be opened and resealed. Telephone conversations can be tapped. Plain-text is easily intercepted on the Internet.

Although this may sound paranoid for a casual user, a large business might think otherwise. It is not uncommon for corporate spies to go through the trash of a company looking for important data. Certain newspapers usually found at the grocery store check-out lane often use this method to get information about public figures, such as movie stars! You can protect sensitive data stored on paper by simply shredding (or burning) it. Protecting data transferred on the Internet is another thing altogether.

A better method for exchanging the symmetric key is to use public/private (asymmetric) key encryption. This type of exchange can set up an encrypted data path that can then be used to exchange the symmetric key for the remainder of the session.

Asymmetric encryption uses both private and public keys, and enables your browser and the Internet server to exchange data without having to first exchange a single encryption key.

Digital Certificates

SSL depends on a private and public key pair for the initial exchange of the symmetric key, as well as for authentication using digital certificates. Public keys are readily available on the Internet from companies that provide digital certificate services. There are several major providers of these sorts of keys, such as VeriSign and Entrust, among many others. Digital certificates are used so that your browser can ensure that the Web server being contacted is indeed who it says it is.

The SSL Handshake Procedure

The SSL handshake procedure uses public/private keys to accomplish the following:

• Determination of the SSL version to be used
• Deciding what type of symmetric encryption will be used
• Server authentication
• Client authentication (optional)
• Exchange of a symmetric key

The exact details of the messages exchanged and the syntax used are a little complicated, but the basic method is as follows:

1. The client sends a request to a server that supports SSL. This message contains such things as encryption techniques and the version of SSL supported by the client, as well as some randomly generated data.
2. The server returns similar information to the client and, if authentication is to be used, the Web server’s digital certificate.
3. The client uses the public key obtained from the Web server to encrypt some data and sends this encrypted data to the Web server. If the client wants to authenticate the Web server (to determine that the digital certificate is valid), it can contact the issuer of the certificate (certificate authority, or CA) and compare the data for the copy of the server’s certificate. The client uses the public key of the CA to determine whether the CA’s copy of the Web server’s certificate is valid. If any data does not match the certificate sent to the client by the Web server, the server is not authenticated and the client ends the exchange between it and the Web server.
4. Assuming that the Web server has been authenticated, the client proceeds to encrypt (using the public key found on the Web server’s digital certificate) some secret data and sends the message to the Web server. The Web server uses its own secret key to decrypt the secret data sent by the client.
5. Both the client and the Web server then go through several steps, depending on the method chosen for symmetric encryption, to come up with a symmetric session key.
6. The client sends a message (encrypted using the newly created symmetric key) to the Web server. From then on, messages between the client and the Web server will use this key. The server replies using the same method, and both sides of the connection send messages indicating that the handshake process is finished.

The preceding steps describe the basic method used to set up an SSL session. Other steps can also be involved. For example, in these steps the client first authenticated the Web server’s certificate by contacting the CA to check the validity of the certificate the client received from the server. The opposite can also be performed: The Web server may need to authenticate the client. This will depend on which way sensitive data is being exchanged. If you are placing an order on a Web site and need to send credit-card information, your browser will definitely want to authenticate the Web server. If the Web server is sending sensitive data to the client (such as when you send confidential data to a customer), the Web server should also authenticate the client so that the server knows that the client is who it appears to be.

Possibly related posts: (automatically generated)
Symmetric and Asymmetric Encryption

• Internet Security, Public Key Encryption and Digital Certificates
• Cryptography MITM Attacks
• Public key Cryptography, when can be seriously Attack
• Dedicated Server with Canadian Web Hosting
• SSL Server（Secure Sockets Layer）
• Web Servers and System Hardening
• Cryptography (Public-Key) Standards and Protocols Notice
• Using Information in the Digital Certificate to Prevent Interception Attacks
• Coded Data Cryptographic Systems Software
• Network Sniffers Do Not See All Packets