You’ve been lied to, or at the very least mislead. Most sources will tell you:
- If you see the little lock icon in your browser
- If you see “HTTPS” instead of “HTTP” in the URL
- If you see the URL background change from white to yellow (depends on the browser)
Then your data is secured. By “secured”, most of us assume this means “The session is authenticated, encrypted and the authenticity of the server has been verified”. Unfortunately, this is not always the case. All the little lock icon tells you is that SSL and TLS is in use. Depending on where you actually see the little lock icon, even that much may not be true.
What is SSL and TLS?
Normally communications on the Internet take place in clear text. This means that anyone looking at your traffic can read it, and just as importantly, change it in transit. The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols are attempts to provide some level of protection for TCP based communications. When you see “HTTPS” in your URL, what that really means is you are running an HTTP session secured by either the SSL or TLS protocol.
We started off using SSLv1. Today we are up to SSLv3 and moving towards TLSv1. What’s the difference between SSL and TLS? For the most part, SSLv3 and TLSv1 are pretty much the same thing. The big difference is that Netscape created and owns the rights to SSL. TLS is an open specification. On the Internet we like to use open standards as often as possible.
Both specifications can be considered “sticky frameworks”. By that I mean the real job of SSL and TLS is to meld together a bunch of other specifications for the purpose of securing a datastream. For example neither defines specifically how to authenticate each packet, they simply point to HMAC-MD5 and HMAC-SHA and say “use that”. Neither specifically tells you how to encrypt the data, they just point to other specifications like RC4, DES and AES and say “use that”. This modular structure is pretty cool as it makes the specifications very flexible. It also ensures that these specifications will not easily be outdated. For example most of us know that DES uses far too small a key size to withstand a modern day brute force attack. No problem for SSL or TLS, just change to another encryption algorithm.
How SSL and TLS work
Both SSL and TLS are pretty lose frameworks. By that I mean that while some things are mandatory, a lot of what goes on in the communication session is optional. Let’s look at a typical session to see what we mean:
The client initiates communications with the server and starts the negotiation. The conversation goes something like this:
Client to server:
“Hi, I can fall back as far as using SSLv2 but would really prefer to use TLSv1. Here are the methods of securing the datastream I support …”
Server to client:
“No problem, I can support TLSv1. Out of the data protection methods you support, here’s the highest one we have in common…”
Server to client:
“Here’s a copy of my digital certificate.”
A couple of things to pull out of this exchange. The client identifies which security protocol it wants to use, but gives the server the option of falling back if required. This help with backwards compatibility, but its key to understanding why your session can end up being less secure than you thought it would be. The same thing happens with the methods or authentication and data privacy. The client identifies what it wants to use, but gives the server less secure options in case they are needed. Finally, the server sends the client a copy of its digital certificate for initial authentication purposes.
All of the above negotiations are required under the SSL and TLS protocol. What happens next however is optional. This is where our problems begin, and I’ll discuss that more in part 2 of this post.