SSL Technically Speaking
Think of your computer in layers. A house or building is built in phases, which also can be thought of as layers. The first layer is preparing the land. The next layer is building the foundation to support the house. On top of that, the framework of the house is built, and after that, at the outermost layers, are your plumbing, electrical, walls, and siding. A computer works in layers as well. The bottommost layer is the foundation, which includes the hardware devices such as the motherboard, processor, and memory. The next layer is the operating system, which runs on top of the hardware. Above the operating system is the application layer, which includes the programs and software you use, such as word processors, Web browsers, and e-mail programs.
TCP/IP is the set of protocols that computers use to communicate. Essentially, it's the language that computers use to speak with each other. For a computer to speak TCP/IP, it must have some software that makes it possible. TCP/IP runs at a layer just above or at the operating system layer, and SSL operates at a layer just above TCP/IP. In other words, SSL depends on TCP/IP to run. Just as SSL uses the TCP/IP layer to do its work, the higher layers can also use SSL to do their work. This is why some of the most popular protocols on the Internet can run using SSL, including HTTP, POP3, and SMTP.
Now that we know SSL operates on top of TCP/IP, the set of protocols through which computers on the Internet communicate, let's look at just how SSL works, in more detail.
Note
 | To use SSL, you must have an SSL-enabled Web browser and you must interact with an SSL-enabled Web site, or server. Most major browsers, including Internet Explorer, Netscape, and Opera, are SSL-enabled. |
SSL is considered a suite of protocols because it actually uses many different standards of key exchange, authentication, and encryption together to get its job done. SSL consists of two main subprotocols: the SSL record protocol and the SSL handshake protocol. The SSL record protocol provides the foundation by defining the format in which data will be transmitted. The SSL handshake protocol uses the record protocol to set up the SSL channel. The SSL handshake protocol is where the server authentication process and the optional client authentication process are done.
How SSL Works in a Typical Transaction
Cryptography is central to the function of SSL. In general, you can picture an SSL session as a tunnel between your Web browser and the Web server. The tunnel provides a protected path for all the transactions that are sent between the browser and server. Information that is exchanged cannot be tampered with or read by anybody but you and the Web server. The tunnel exists solely for your session with the Web server. After the tunnel has been created, your information exchanges are safe. When the tunnel is destroyed, you are once again open to the basic threats of the Internet described earlier. The Web server or the Web browser typically destroys the SSL tunnels when the need for protection is over or the session is finished because you leave the site.
This is how SSL works:
You visit a Web site (the server) that is SSL-enabled by using the https:// prefix.
The server sends its digital certificate to you, and your Web browser verifies the authenticity of the certificate by querying the signing Certificate Authority. If the CA is unknown or is not listed in your browser's database of CAs, the Web browser alerts you and asks whether you want to accept it. If the certificate is not accepted or does not exist, the SSL session cannot be established, and the connection is stopped.
Your Web browser then takes the information in the server's certificate and computes what is called a premaster secret. This premaster secret then is encrypted with the server's public key and sent to the server.
When the client's premaster secret is accepted, the server continues the secure key exchange. Optionally, if the server wants to authenticate you, it asks your Web browser to send over your client certificate, which it attempts to validate against a signing CA.
The server uses its private key to decrypt the premaster secret and then takes some steps to compute the master secret. (Your Web browser actually does the same thing, performing a series of steps with the premaster secret, to derive a master secret. This master secret is the same for your Web browser and the server.)
Your Web browser and the server both use the master secret to generate session keys. The session keys are used for the encryption and decryption of further communications to prevent eavesdropping. They are also used to help detect any tampering with the communications.
Your Web browser and the server let each other know that they have the session keys and continue using them. The handshake process has completed, and an SSL tunnel has been successfully set up.