TLS, SSL & the Handshake
When you load https:// and see the padlock, TLS is the reason. (You will hear SSL too, it is the older name for the same family; people use them interchangeably, though modern connections use TLS.)
What TLS gives you
TLS ensures you are interacting with the legitimate website, and that nobody can read or modify the data in transit. Three guarantees in one:
- Identity, you are really talking to that site (proved with a certificate, next lesson).
- Confidentiality, eavesdroppers see only ciphertext.
- Integrity, tampering in transit is detected.
Where it sits
Recall the request journey: TCP first, then TLS, then HTTP. TLS runs on top of the TCP connection. Once the TCP pipe exists, the two sides perform the TLS handshake before any real HTTP data is sent, encryption has to be agreed before secrets travel.
The handshake, at a high level
- ClientHello, "here are the TLS versions and ciphers I support."
- ServerHello + Certificate, the server picks a cipher and sends its certificate (its identity).
- Key exchange, both sides agree on a shared secret key.
- Finished, both switch to encryption; everything after is private.
The elegant part: the client and server end up with the same secret key without ever sending that key across the wire in the clear. From the "Finished" message onward, every HTTP request and response is encrypted with it.
Why a tester cares
The handshake is where trust is established, so it is where trust can fail: an expired certificate, a name mismatch, a user clicking past a warning, or a forced downgrade to weaker crypto. The next lesson opens up the certificate that step 2 relies on.
Takeaway
TLS turns the open TCP pipe into a private, authenticated channel. It proves who you are talking to and hides what you say, and it does the whole negotiation up front, before the first byte of real data.