How SSL works
				(1) Client sends a request to the server for a secure SSL/TLS session. (2) Server sends its certificate from a recognized certificate authority, such as VeriSign or Entrust, to the client for authentication along with its public key. (3) Client receives the server's certificate, verifies it, and creates a one-time session key using the server's public key, and sends it to the server. Server decrypts the session key using its private key and establishes a secure tunnel.

Why TLS?
SSL and TLS both use cryptography to provide authentication and privacy to Internet communications. TLS was designed to replace SSL, and identifies itself in the protocol version field as SSL 3.1. There are a handful of minor differences.

So, why create a new protocol? Because SSL, created by Netscape about a decade ago, is a closed proprietary protocol. The community cannot make changes or validate its security. The Internet Engi-neering Task Force (IETF) created TLS, an open version of the protocol, so everyone would be free to use and comment on it.

In practice, it does not matter which you select. But since more organizations are migrating to TLS, it will give you a wider range of support.

Nevertheless, though very similar, SSL and TLS are not interoperable. This means that if your server is set up to utilize TLS, it isn't downward compatible with clients only using SSL. Newer browsers and other Web applications support both SSL and TLS, so this is generally not much of an issue.

How SSL and TLS Work
At a high level, it's simple: A key is established between the sending and receiving computers, the information is encrypted with the key, and the encrypted information is transmitted (see "How SSL Works"). However, there are important details to understand.

First, the encryption is done by the application, not the operating system. The application programmer doesn't have to implement the protocol, but must specify a secure socket when establishing a connection. A socket is simply a special type of file descriptor. Instead of specifying the name of the file to be opened, the IP address and port of the destination computer are specified. The operating system packages this data into packets and sends them to the appropriate spot. Low-level work, like calculating checksums and tracking sequence numbers, is done by the operating system.

SSL and TLS protocols work in three basic steps:

1. Negotiation occurs between the client and server on the use of TLS or the version of SSL (2.0 or 3.0). This step also decides the cipher that is to be used for the rest of the protocol exchange. There are a number of public and symmetric key encryption algorithms that can be used.
2. After ciphers have been negotiated, the server is authenticated and a symmetric key is created to be used throughout the rest of the communication. This is all done using public key algorithms and X.509 certificates. This certificate is issued by a certificate authority (CA), a trusted third party that verifies the identity of the server.
   
   This one-sided authentication is all that is required; users must know they are talking to the proper server, not an impostor--such as a bogus bank site used in a phishing scam. The user then provides his user name and password, or multifactor authentication.
3. The symmetric key is sent to the server using public key encryption. The public key for the server is included in the certificate validated by the CA. After the symmetric keys have been established and exchanged, communications are encrypted using symmetric key algorithms instead of the public key one used before. This is done simply because symmetric key algorithms are faster and computationally easier to use. All client-server traffic is now encrypted using this key until the connection is dropped or the key expires. This provides a secure tunnel of communication.