Main content
Course: Computers and the Internet > Unit 4
Lesson 6: Secure Internet protocolsTransport Layer Security (TLS)
Computers send packets of data around the Internet. 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. TLS uses both symmetric encryption and public key encryption for securely sending private data, and adds additional security features, such as authentication and message tampering detection.
TLS adds more steps to the process of sending data with TCP/IP, so it increases in Internet communications. However, the security benefits are often worth the extra latency.
(Note that TLS superseded an older protocol called SSL, so the terms TLS and SSL are often used interchangeably.)
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.
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.
TLS everywhere
TLS is used for many forms of secure communication on the Internet, such as secure email sending and secure file upload. However, it's most well known for its use in secure website browsing (HTTPS).
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.
🙋🏽🙋🏻♀️🙋🏿♂️Do you have any questions about this topic? We'd love to answer—just ask in the questions area below!
Want to join the conversation?
TLS was proposed by the Internet Engineering Task Force (IETF), an international standards organization, and the first version of the protocol was published in 1999. The most recent version is TLS 1.3, which was published in 2018.
If you are satisfied by this information, please put an Upvote on me and Grace.(32 votes)
i dont understand the pre-master key and shared key, "first use public key encryption to privately generate a shared keys"
then the next paragraph, "client computes the shared key based on that pre-master key"
so the shared key comes from public key or pre-master key?
and where does pre-master key come from?(14 votes)
The shared key for symmetric key encryption is computed from the pre-master key. The client generates the pre-master secret, has access to it, and encrypts it with the server's public key before sending it to the server.
The server gets access to the pre-master key by decrypting the message. Now, since the server and client both have access to the pre-master secret, they both compute the same shared symmetric key for the next step.
Hope that helps!(15 votes)
- What's the use of the server sending its own "Finished" message with contents encrypted with the shared key? Is it to let the client know that the server understands the encryption technique?(2 votes)
- Great question. The server's message represents confirmation of a successful TLS handshake in which the ChangeCipherSpec encodes the agreed-upon encryption technique. Here is a helpful link I found to see this: https://tls.ulfheim.net/
Hope this helps!(7 votes)
So the process as I understand is
1. The server creates a public and private keys and send the public key to the client.
2. The client creates a pre-master key and encrypted it using the public key.
3. The client creates a shared key and encrypted using the pre-master key.
4. The client sends both the encrypted pre-master key and shared key to the server.
5. Now the server uses the private key to decrypt and get the pre-master key and then uses the pre-master key to decrypt and get the shared key.
6. The server and client communicate with each other using shared key.
Is my understanding correct?
If so then after step 5 the private key, public key and pre-master key are pretty much useless right? Because the client and server use the shared key and don't need the other keys anymore.(3 votes)
The Public key pair is created when the client connects and it receives the public key in the response.
In the handshake the server and client exchange random values and then only the encrypted pre-master key is sent to the server. Using that and the random values, the server can create the same shared key as the client did.
This differs also depending on what ciphers are chosen in the handshake. Google TLS handshake for more detailed information.(3 votes)
How do hackers obtain a person's information even with a secure connection?(4 votes)
What is TLS and TCP in simple terms? How do they relate to each other?(3 votes)- Will there be a possibility for rouge access (attackers) to see the pre-master key and change the data?(2 votes)
- In general, it is extremely difficult for attackers to intercept and modify encrypted data transmitted over a secure connection, such as one protected by the Transport Layer Security (TLS) protocol, which is commonly used to secure internet communications, including HTTPS websites.
However, there have been some instances where vulnerabilities in TLS implementations or cryptographic libraries have been exploited by attackers to compromise the security of encrypted connections. One such vulnerability is the "Heartbleed" vulnerability, which affected the OpenSSL cryptographic library in 2014. Heartbleed allowed attackers to exploit a flaw in the TLS heartbeat extension to leak sensitive information, including the private keys used to secure encrypted connections.
While vulnerabilities like Heartbleed are rare and typically quickly patched by software developers, they highlight the importance of maintaining up-to-date software and security protocols to protect against potential attacks.
In addition to vulnerabilities in TLS implementations, attackers may also attempt to compromise encrypted connections through other means, such as social engineering attacks, malware infections, or attacks on the endpoints of the connection (e.g., the client or server). For example, attackers may use phishing attacks to trick users into installing malicious software or disclosing sensitive information, which can then be used to intercept or modify encrypted communications.(3 votes)
- i dont understand the pre-master key and shared key, "first use public key encryption to privately generate a shared keys"
then the next paragraph, "client computes the shared key based on that pre-master key"
so the shared key comes from public key or pre-master key?
and where does pre-master key come from?(0 votes)