SSL/TLS Explained
Practice this topic in a realistic system design interview
Suppose you connect to the Wi-Fi at a coffee shop and log in to a website. Your browser sends your username and password over the network. That data passes through the Wi-Fi router, your internet provider, and several other networks before it reaches the server.
If the connection is plain HTTP, every one of those machines can read it. Someone on the same Wi-Fi network could capture your password.
But reading is not the only risk. An attacker in the middle could also modify the response, for example by injecting a malicious script into the page. Or they could pretend to be the website entirely and collect your credentials themselves.
So a secure connection needs to solve three problems:
- Confidentiality: nobody else should be able to read the data.
- Integrity: nobody should be able to change it without being detected.
- Authentication: the client should be sure it is talking to the real server.
TLS provides all three. It is the security layer behind HTTPS, and it also protects databases, message brokers, and internal service-to-service traffic.
In this chapter, we will look at what TLS is, how the TLS handshake works, how certificates prove a server's identity, and where TLS fits in a real system design.
Loading simulation...