Main content
Course: Archived AP CSP content > Unit 1
Lesson 5: Archived Secure data transportTransport Layer Security (TLS)
Computers send packets of data around the Internet using the TCP/IP protocols. These packets are like letters in an envelope: an onlooker can easily read the data inside them. If that data is public information like a news article, that's not a big deal. But if that data is a password, credit card number, or confidential email, then it's risky to let just anyone see that data.
The Transport Layer Security (TLS) protocol adds a layer of security on top of the TCP/IP transport protocols. It takes advantage of both symmetric encryption and public key encryption for securely sending private data, and adds additional security features like authentication and message tampering detection. (Note that TLS was formerly known as SSL, so the two terms are often used interchangeably.)
TLS adds more steps on top of TCP/IP, so it increases latency in Internet communications. However, the security benefits are often worth the extra latency.
From start to finish
Let's step through the process of securely sending data with TLS from one computer to another. We'll call the sending computer the client and the receiving computer the server.
TCP handshake
Since TLS is built on top of TCP/IP, the client must first complete the 3-way TCP handshake with the server.
TLS initiation
The client must notify the server that it desires a TLS connection instead of the standard insecure connection, so it sends along a message describing which TLS protocol version and encryption techniques it'd like to use.
Server confirmation of protocol
If the server doesn't support the client's requested technologies, it will abort the connection. That may happen if a modern client is trying to communicate with an older server.
As long as the server does support the requested TLS protocol version and other options, it will respond with a confirmation, plus a digital certificate that contains its public key.
Certificate verification
The server's digital certificate is the server's way of saying "Yes, I really am who you think I am". If the client doesn't believe the certificate is legit, it will abort the connection, since it doesn't want to send private data to an imposter.
Otherwise, if the client can verify the certificate, it continues on to the next step.
Shared key generation
The client now knows the public key of the server, so it can theoretically use public key encryption to encrypt data that the server can then decrypt with its corresponding private key.
However, public key encryption takes much more time than symmetric encryption due to the more difficult arithmetic operations involved. When possible, computers prefer to use symmetric encryption to save time.
Fortunately, they can! The computers can first use public key encryption to privately generate a shared key, and then they can use symmetric encryption with that key in future messages.
The client starts off that process by sending a message to the server with a pre-master key, encrypted with the server's public key. The client computes the shared key based on that pre-master key (as that is more secure than sending along the actual shared key) and remembers the shared key locally.
The client also sends a "Finished" message whose contents are encrypted with the shared key.
Server confirmation of shared key
The server can now compute the shared key based on the pre-master key, and attempt to decrypt the "Finished" message with that key. If it fails, it aborts the connection.
As long as the server can successfully decrypt the client's message with the shared key, it sends along a confirmation and its own "Finished" message with encrypted contents.
Step 3: Send secure data
Finally, the client securely sends the private data to the server, using symmetric encryption and the shared key.
Oftentimes, the same client needs to send data to a server multiple times, like when a user fills out forms on multiple pages of a website. In that case, the computers can use an abbreviated process to establish the secure session.
Certificate verification
In the TLS process above, the client does not send any data to the server until it has received and verified its digital certificate. That certificate verification step is a crucial part of what makes TLS so secure.
Why? Cybercriminals have many ways that they can intercept a request from one computer to another computer on the Internet, like DNS spoofing. A cybercriminal could route the TLS request to their own server instead, and respond with their server's public key.
If the client does not properly verify the authenticity of the certificate, then it will complete the TLS handshake and send private data to the cybercriminal's server, which will happily decrypt the data.
The client has shielded the rest of the Internet from seeing the data, but they delivered the secret straight into the enemy's hands!
Clients rely on certificate authorities to verify that a certificate (and its public key) belongs to a particular domain.
Any server that wants to communicate securely over TLS signs up with a certificate authority. The certificate authority verifies their ownership of the domain, signs the certificate with their own name and public key, and provides the signed certificate back to the server.
When the client inspects the certificate, it can see that a certificate authority is vouching for the authenticity of the public key. But it still has a decision to make: does it trust that certificate authority?
Clients generally come bundled with a list of trusted certificate authorities. For example, an Apple iPhone running iOS 10 trusts this long list of certificate authorities.
Apple users then have to trust Apple to continually monitor that list to make sure each certificate authority is verifying domains properly.
You can imagine a chain of trust from the user to the server:
At each point, trust can be broken. If the user doesn't trust the client, they can override the client's default list of trusted certificate authorities. If a client no longer trusts a certificate authority, it will remove it from the list. If a certificate authority sees suspicious behavior from a server, it can revoke its certificate.
TLS everywhere
TLS is used for many forms of secure communication on the Internet, like secure email sending and secure file upload. However, it's most well known for its use in secure website browsing (HTTPS), which we'll explore more in the next lesson.
TLS provides a secure layer on top of TCP/IP, thanks to its use of both public key and symmetric encryption, and is increasingly necessary to secure the private data flying across the Internet.
Want to join the conversation?
Is the "math operation" used by the client and server to compute the shared key referred to the agreed/negotiated cipher suite?(4 votes)- Yes, the math operations are defined by the agreed upon cipher suite. You may find this interesting: https://www.acunetix.com/blog/articles/establishing-tls-ssl-connection-part-5/(1 vote)
- Just briefly as I know it will come up in the later lessons, what r cookies?(1 vote)
Cookies are pieces of information about the website and your interaction with it. Generally, they store information such as whether you are logged in to an account, what items you've placed in your shopping cart, how many times you've visited the website, etc.(2 votes)
Under the "Shared key generation" section, it says (if I understand it right) that the pre-master key is sent by the client using the server's public key. Then they compute the shared key from the pre-master key.
Why can't the client just create the shared key in the first place, and send it using the server's public key? Thanks in advance!(1 vote)- This is a nice observation! The reason I'm aware of is from here: https://crypto.stackexchange.com/questions/24780/what-is-the-purpose-of-pre-master-secret-in-ssl-tls
Without getting too specific, the basic idea is that it enables consistency between different algorithms used in TLS. You can imagine one algorithm generates one format and another algorithm generates another format. Sending data in a defined encoding that handles both formats (as well as future ones) can lead to inconsistencies.
Hope this helps!(2 votes)
Where it says that the client uses mathematical operations to create a shared key based on the pre-master key, do they mean the server or the actual client?(1 vote)- I believe they mean the actual client. I think the larger point is that the client and server will both possess the shared key at some point that is created based on the pre-master key.(2 votes)
Why doesn't normal public key encryption switch to symmetric key encryption also?
How do people as client users request TLS connections?(1 vote)
Public key encryption is a pretty solid encryption scheme, there is no real reason to change to symmetric encryption, especially as the public key encryption is the newer encryption scheme :^)
If you look at the url you see that it's https instead of http, which means that you're already using TLS to access this site.(1 vote)
- So, in summary, symmetric encryption is faulty because you need to use un-encryted communication to send it. Public key encryption is faulty because it is time consuming, so TLS goes into effect on request of the client, and it uses public key encryption to send over a symmetric key to save time in the future?
How do computers know when one computer wants to use TLS?(1 vote)- Faulty isn't really the right word, it's more like different kinds of encryption have different advantages and disadvantages.
TLS is an additional layer of security, making your TCP/IP connection more secure. The article explains how it works in detail.
It communicates that desire. After the connection has been initialized, it's sends a message to inform the other machine, that a secure connection is to established.(1 vote)
So does this mean that Godaddy was usd by Khan academy to make their website?(1 vote)