About Code Collections Diversions Musings Personal Photos Search
Printer Friendly Version of This Page Secure Socket Layer / Transport Layer Security Explained.

    So you want to know all about securing your communications on the World Wide Web, eh? Well, make yourself comfortable and let grandpa tell you a story..

    Back when the Internet was young and web access was only within the reach of educational institutions, the military and well-off early adopters, people didn't worry all that much about the information they sent over the interconnecting networks that composed the World Wide Web. This attitude was somewhat akin to how people didn't lock their doors or have car alarms and such back in the nostalgic "good old days". As became the case with homes and automobiles, keeping information safe from prying eyes and thieves on the Internet is a huge concern today. As more and more people make the transition to the "online" world, so to is there in increase in unscrupulous individuals looking to be the digital equivalent of a "Peeping Tom".

   At a very basic level, information you send to a machine over the Internet (a web site, for instance), or that is sent to you via the Internet goes through a series of networks ("hops") en route to its final destination. Picture it like a piece of postal mail - many people handle it, load it onto trucks, airplanes, etc. At every "hop" your mail takes, there is a chance that someone can steam open the envelope or hold it up to the light and take a look inside. What makes matters worse is that unsecured Internet communications are more like postcards than letters in envelopes; all your information is presented clearly for any of the handlers to see. While this may not bother most people in their daily web surfing (news sites, search engines, etc.), this isn't an ideal way to send financial (via your bank or broker's web site) or otherwise confidential information. Clearly, a more secure way of concealing the messages on those billions of postcards zipping across the network is needed.

   The answer to the problem is encryption. The Secure Socket Layer (SSL) was developed by Netscape to allow two machines encrypted, secured communications despite the number of network "hops" between them. The Internet Engineering Task Force (IETF) drafted a standard based on Netscape's SSL, the lesser-known acronym TLS - Transport Layer Security, that is supported by just about every major web browser, web server, and email client. Simply put, this system allows data to be encrypted during the trip from your web browser to the remote web server and vice-versa. What kinds of data, you ask? Just about everything, from the name of the web page you're viewing to your name, address, phone number, email address and other items you may provide on a web form.

   Now that we've established why we need SSL / TLS and a basic idea of what it is, let's dig a bit deeper into how it works. It all begins with a request from your web browser. Let's say you click on a link or type into the address bar: "". Note the "s" in "https". Normal, unsecured web communications have a protocol identifier of "http", an acronym for HyperText Transfer Protocol. The trailing "s" tells your web browser to try and initiate a secure communications channel when sending and receiving data from the remote web site. Before we cover how your browser and the remote server actually set up the secured communication ("handshake"), we'll need to take a side-trip and look at public key encryption.
The most well-known form of encryption is symmetric-key encryption, commonly used in substitution ciphers. The basic idea is that all parties involved share a common key, used to both encrypt and decrypt messages. Newspapers for years have carried a daily puzzle called the "CryptoQuip" which presents you with a message encoded via a substitution cipher. Each letter in the original message is represented by a (normally) different letter in the encrypted version. Here's an example that I use in my random signature file quotes, attributed to Kevin McCurley:
"When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl."
Looking at the second part of the message, "bayl bhgynjf jvyy unir cevinpl" , we see the use of a substitution cipher. In this case, the letter "b" has been substituted for the letter "o", "a" for "n" and so on. The message, when decoded, reads:
"When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl."
"When cryptography is outlawed, only outlaws will have privacy."
When the two lines are laid out above in a mono-spaced font, it's quite easy to see the "key" used for this message. The problem with symmetric-key encryption is that once a key is compromised, the whole system falls apart. Since the same key is used to encrypt and decrypt, false messages could be sent and any further messages encrypted with this key are as good as read. Another issue that arises from this is how to distribute a new key to the other parties without it being compromised in transit.

Public-key encryption, or "PKE", uses a bit of mathematical theory to address most of these shortcomings. In public-key encryption, you have a private key that is kept secret and known only to you. If this key is leaked, the whole encryption scheme becomes worthless. For others who want to send encrypted messages to you, you have a public key. This key is not intended to be a secret by design and can be distributed on websites, public key servers, even published in the New York Times! Unlike symmetric-key encryption discussed earlier, only your private key can be used to encrypt messages as you or decrypt messages encrypted for you. Thanks to the underlying mathematical theory, your private key cannot be derived from your public key, making the whole system more secure. This system all boils down to the difficulty involved in factoring large numbers into products of primes; more on this at the end of this document for those who are interested.
Now that we know the basics of PKE, let's take a look at the initial handshake that sets up the SSL session. Your browser will connect to the server on the SSL port (tcp/443) and send some basic, non-confidential information to the server, such as which cryptographic methods the client supports, SSL version, etc. The server will then respond with its list of supported ciphers, SSL version and other necessary information. Included is a copy of the server's certificate and public key. The certificate is then validated by the client (more on that later). If the client is satisfied, it will generate a secret key to be used during the secured session, encrypt it using the server's public key, then send it to the server. The server will then send a final message back to the client, encrypted with the client's generated secret key, to indicate the handshake has been completed. From this point on, all communications for the session will be encrypted using the new "shared" secret key. As a user, your indication that the connection is encrypted usually comes in the form of a locked padlock icon in your web browser's status bar. Note that this key is only used for this session; new sessions will require re-negotiation and in all likelihood, a new shared key.

   By now, if your eyes haven't glazed over and you're still reading this, you may be wondering if encryption is the only benefit of using SSL / TLS on a web site. Well, hold on to your hat because it's not! All sensitive communications on the Internet always boil down to a matter of trust. If I can't trust your web server to use and guard my data properly, who cares if the connection is encrypted? My information, while safe in transit, may still be at risk if you're not the person(s) for whom it was intended. In other words, just because your site looks and feels like, how can I be sure it's not some clever trick by some miscreant bent on grabbing my credit card number? Here's where that "server certificate", mentioned briefly during the SSL handshake discussion earlier, comes in to play.

   SSL certificates contain information about the individual or organization that uses them. Certificates provide the individual or organization's name, location, email address, server name and the dates during which the certificate is valid. This is all well and good until you realize that it would be trivial for someone to make up a certificate that says they are "", regardless of their true identity. To overcome this, Certificate Authorities (CA) were created. A Certificate Authority is an organization that is trusted to vouch for whether a person is who they say they are, somewhat like a Notary Public in the offline world. In order to certify a certificate, the CA will investigate the identity of the requester and, if satisfied, "sign" the SSL certificate. When the server presents this signed certificate to the client during the SSL handshake, the client will attempt to verify the signature against a list of "known good" signers. Web browsers normally ship with lists of CAs that they will implicitly trust to identify hosts. If the authority is not on the list, like some sites that sign their own certificates, the browser will alert the user that the certificate is not signed by a recognized authority and ask the user if they wish to continue communications with the unverified site. Users can add custom certificate authorities to the browser's list of trusted signers, thus solving the problem of being prompted every time you visit the same self-signed site. If the today's date falls within the certificate's valid time range, the host name matches and the certificate was signed by a trusted authority, you can be reasonably certain that you are communicating with the site you intended to. As a final precaution, you can always verify the information for yourself by clicking the little "lock" icon in your browser window and looking through the certificate details.

   No discussion on SSL / TLS would be complete without a paragraph on encryption strength. If you recall our mini-discussion on public-key encryption (you were paying attention, weren't you?), we talked about public and private keys and that the whole system was based on the difficulty of uncovering the private key used to encrypt and decrypt messages. What we managed to gloss over is how the size of that key impacts the ideal amount of time required to break the encryption. Yes, I said "break the encryption"; it is possible! Public-key encryption strength is expressed in terms of "bits", as in the common standard of "128-bit encryption". What this means is that the key used contains 128 bits, each "bit" being either a "1" or a "0". Ignoring the possibility of a lucky guess, a brute-force method of uncovering a 128-bit key would require testing a worst case of 2128 combinations of ones and zeroes. I say worst case because you would only need to try every combination if the one used was the last possible combination. To get an idea of the sheer size of this number, imagine the number three followed by thirty-eight zeroes! Definitely not for the faint of heart! Even if you had a modern 4GHz machine capable of trying one combination per cycle dedicated to the task of cracking a key of this strength, it would take you roughly 2.6x1021 years (2.6 sextillion!) to try every combination. However, if you take the bare minimum encryption level supported by most browsers (excepting no encryption), 40-bit or 240 combinations, the same machine could try every key within a matter of minutes. Of course, these theoretical numbers do not take into account the normal overhead of running an operating system and other user processes that would reduce the amount of cycles dedicated to cracking the key. What they do show is the tremendous difference in effort between the 128-bit and 40-bit strengths. Therefore, to obtain the best encryption supported by most browsers and servers, you'd definitely want the sites you visit securely (and your browser) to support 128-bit encryption.

   So there you have it. Never again will you feel the need to sulk away in shame when those "techies" start talking about SSL and encryption at wild parties (ha!). I've tried to keep this as simple and light on the techno-babble as possible, even going so far as to gloss over the finer points of encryption schemes and using RSA as the only model. Those of you still yearning for more technical or in-depth information might want to consult the resources listed below. As a final note, I didn't bother to touch on the paranoia some folks have over the fabled ability of the CIA/FBI/NSA/Insert-Three-Letter-Acronym-Here to break any strength encryption faster than Mr. Coffee™ can brew a a fresh pot. Believe what you will, tinfoil hat or not, SSL / TLS helps to keep your stuff safe from prying eyes. Well, at least in transit...


We support open web standards. This page contains both Valid XHTML 1.0 and Valid CSS .
Unless otherwise noted, all content © 2000 - 2006 Scott Sorrentino.

Version History
Created:   31 July 2003