Question: What part of a TLS/SSL request is encrypted?
As a Senior Developer at CQL, one of my responsibilities is to interview prospective developers. One question I often ask is: What part of a TLS/SSL request and associated response are encrypted?
I’m surprised by how many people, even those with extensive web development experience, either admit they don’t know or answer the question wrong.
No single question will make or break a candidate. And yes, the answer can easily be found on Google. What I’m looking for isn’t necessarily a correct answer, but an ability to reason about what they do know. Or, at least a willingness to understand what goes on under the hood instead of just reclining in the driver’s seat and cruising along.
So, I thought I’d give a quick overview of what happens when the lock icon shows up in your address bar and also hopefully get you curious enough to research a bit more (even if it’s not specifically about this topic!).
Let’s start out at a basic level.
TLS stands for ‘Transport Layer Security.’ It’s the continuation of what used to be ‘Secure Socket Layer’ or SSL, which was redefined as TLS in 1999. It defines a protocol for secure communication between two parties.
It also provides some level of authentication that the two parties are who they claim to be, though this authentication is not perfect (we’ll get into this a bit below).
One interesting aspect of TLS (besides the fact that we still call it SSL 15 years later) is that its only goal is to securely pass data between the two parties. It explicitly does not try to define what that data is.
This means it can be used for more than just securing HTTP communication, like to secure FTP (File Transfers), SMTP (Email), and VPN (Virtual Networks).
At this point, even though we really haven’t talked about how it works, you should have enough information to reason about and come up with a good educated guess for the answer to my interview question! I’ll give you a few more paragraphs to think about it though.
Getting into the details.
What happens when you click the ‘Checkout’ link of an eCommerce site or a bookmark to go to your favorite social networking site?
The most obvious change is the lock icon that appears in your address bar, and the URL starts with https:// instead of http://. Behind the scenes a lot more just happened.
First, your web browser noticed the URL was a secure address because of the protocol prefix (https://). The browser send a special message to the server, which is the first step in a ‘handshake’ between the two computers.
The message includes the version of TLS the browser plans to use, details about what encryption methods and compression methods the client knows, and a string of random data.
The server responds with its own message to let the client know which encryption method and compression method to use (selected from the lists the client sent), the version of the TLS protocol the server will use, and a separate string of random data generated by the server.
The ‘handshake’ between the two computers continues for a few more messages. These messages differ based on the encryption method and whether the server and client will use certificates to provide any of the encryption keys and basic authentication.
This step provides some basic state information used for encryption (e.g. the encryption key and initialization vector information), and also ensures this information isn’t also visible to someone eavesdropping on the conversation. At this point, the available certificates are exchanged and verified.
Finally, the two parties have the basic shared state, accepted the certificates, and agreed on an encryption method. At this point, they each send one last unencrypted message, telling each other to start using encryption.
Now that the encrypted TLS channel exists, the rest of the communication (in our case, HTTP) happens exactly like over an unencrypted channel. The browser creates a ‘GET’ request with the requested document, query string, cookies, etc, and sends it to the server over the TLS channel. The server creates a response message and returns it over the encrypted TLS channel.
Answer: All of it.
Back to my interview question: What parts of the request and response are encrypted? As you can see, all of the communication is encrypted*!
This means that machines between the server and client can’t see any of the data that is sent back and forth. However, don’t expect this to mean that it is 100% secure. Security exploits for the protocol are occasionally found.
If you run a website using an SSL certificate for security, you should make sure that your server is up to date with patches and do some research about what cryptography suites you should have enabled/preferred (current recommendations include disabling RC4 and 3DES, for example).
Remember these recommendations do change over time, so you should perform this research regularly.
Additional Resources
Want to learn more? Here are a few pages that I recommend for more technical knowledge:
- TLS Protocol. This is the specification itself. Not the easiest place to get information, but any time you are researching a topic (not just TLS), the specification should always be near the top of your list of sources!
- The Wikipedia page on TLS, which includes the history of the protocol, details on how it works, and some of the known security exploits.
- The First Few Milliseconds of an HTTPS Connection. This is a very detailed blog post that breaks down the handshake step by step when initiating a connection to Amazon. It’s a few years old now and the protocol has had a few minor revisions since then, but still a fascinating and relevant post.
*There’s one bit of data that’s passed unencrypted from the client to the server during the handshake, do you know what that is? Hint: this is a common extension to TLS.
