Why TLS
TLS — Transport Layer Security — wraps an ordinary TCP connection in a session that gives it three properties at once: confidentiality, so anyone reading the wire sees only ciphertext; integrity, so any tampering with the bytes is detected and the connection torn down; and authentication, so you have cryptographic proof you are talking to the server you named, not a machine in the middle pretending to be it. HTTPS is exactly HTTP carried inside such a session, on port 443.
The three guarantees are separable, and that is the single most important thing to internalize on this page. A connection can be encrypted yet wide open to a machine-in-the-middle, because encryption to the wrong party is still encryption. Knowing which guarantee a given mechanism delivers — and which it silently does not — is the foundation for every certificate and handshake topic that follows.
The Three Guarantees
Confidentiality defeats the passive eavesdropper: the attacker who can copy every packet but not change them. TLS encrypts the application bytes with a symmetric cipher such as AES-256-GCM or ChaCha20-Poly1305, so a captured pcap is noise without the session key. Integrity defeats the active tamperer: each record carries an authentication tag, and a single flipped bit makes the tag fail, so the receiver rejects the record rather than acting on altered data.
Authentication defeats the impersonator. The server presents a certificate binding its public key to its domain name, signed by a Certificate Authority your system already trusts, and proves it holds the matching private key during the handshake. Without this third guarantee the other two are worthless — you would have a perfectly encrypted, tamper-proof channel to an attacker. That is precisely what a machine-in-the-middle attack exploits when certificate validation is skipped.
Symmetric versus Asymmetric Cryptography
Symmetric crypto uses one shared key for both encryption and decryption. It is fast — modern CPUs do AES in dedicated instructions at gigabytes per second — but it has a fatal bootstrapping problem on an open network: both sides need the same secret key, and you cannot send that key over a channel an eavesdropper is already watching.
Asymmetric (public-key) crypto uses a key pair: a public key anyone may hold and a private key the owner guards. Data encrypted to the public key only the private key can read, and a signature made with the private key anyone can verify with the public key. This solves key distribution — you can publish a public key openly — but it is two to three orders of magnitude slower than symmetric crypto, far too slow to encrypt a video stream byte by byte.
The Hybrid Model
TLS uses both, each for what it is good at. The handshake uses asymmetric crypto to authenticate the server and to agree on a fresh random session key without ever transmitting that key in the clear. Once both sides hold the session key, every byte of application data is encrypted with fast symmetric crypto. Asymmetric work happens once per connection; symmetric work carries the bulk traffic.
This is why TLS pays a measurable cost at connection setup — the handshake's public-key operations and round trips add latency — but almost none thereafter. A long-lived HTTPS connection moving gigabytes runs at near line rate because, after the handshake, it is just AES-GCM over TCP. The expensive part is amortized across the whole session.
What TLS Does Not Do
TLS secures the connection, not the endpoints. It says nothing about whether the server you authenticated is itself compromised, whether the application running on it has an SQL-injection bug, or whether the data is stored encrypted at rest. A valid padlock means the bytes reached the right server safely; it makes no claim about what that server does with them.
TLS also leaks metadata. Even on TLS 1.3, the destination IP is visible to anyone on the path, and the SNI (Server Name Indication) field in the ClientHello — the hostname you are connecting to — is sent in cleartext so the server knows which certificate to present. Encrypted ClientHello (ECH) closes the SNI hole but is not yet universal, so for most traffic an observer still learns which site you visited even though they cannot read what you sent.
Encryption hides the content of the connection from anyone watching the wire. On its own it proves nothing about who is on the other end — an encrypted channel to an attacker who terminated your TLS session is still fully encrypted, and the attacker reads everything in plaintext on their side.
Authentication proves the other end is who it claims to be, via a certificate chain the client validates. Encryption without authentication is the classic machine-in-the-middle setup; you need both, which is why disabling certificate verification "to make it work" silently removes the guarantee that actually keeps the attacker out.
- Assuming encryption implies authentication. A connection can be perfectly encrypted to an attacker who terminated your session; without validating the certificate chain, the padlock means nothing and the machine-in-the-middle reads everything.
- Disabling certificate verification — curl -k, verify=False, InsecureSkipVerify: true — to silence an error. It removes the authentication guarantee entirely, turning a hard failure into a silent vulnerability that no longer alerts anyone.
- Believing TLS hides which site you visit. The destination IP and the cleartext SNI hostname in the ClientHello reveal the site to any on-path observer; only the request contents are hidden unless Encrypted ClientHello is in use.
- Treating HTTPS as application security. TLS protects bytes in transit, not a vulnerable app or an unpatched server — a valid certificate does nothing to stop an injection bug behind it.
- Using asymmetric crypto for bulk data. RSA or ECDSA operations are two to three orders of magnitude slower than AES; encrypting a stream with them instead of a negotiated symmetric key cripples throughput.
- Treat the three guarantees as a set: verify that confidentiality, integrity, and authentication are all in force, since any client that skips certificate validation keeps the first two and throws away the one that stops a MITM.
- Fail closed on certificate errors. Let an invalid or expired certificate break the connection rather than wiring in a bypass; the error is the security control doing its job.
- Pin to a known CA or certificate for high-value client-to-server links, so a mis-issued certificate from any other CA in the trust store cannot be used to impersonate your backend.
- Encrypt sensitive data at rest as well as in transit, because TLS protects only the wire and leaves stored bytes exposed to anyone with access to the server.
- Adopt Encrypted ClientHello where your clients and CDN support it to close the SNI metadata leak, instead of assuming TLS already hides the hostname you connect to.
Knowledge Check
A client connects over TLS with a strong cipher but with certificate verification turned off. Which guarantee has it lost?
- Authentication — it may now have an encrypted channel straight to an impersonator
- Confidentiality, since the cipher no longer hides the application bytes on the wire
- Integrity, because tampered records will now be accepted by the receiver
- None — encryption alone still keeps the connection fully secure
Why does TLS use asymmetric crypto for the handshake but symmetric crypto for the application data?
- Asymmetric solves key distribution but is slow, so the fast symmetric cipher carries the data
- Symmetric crypto is cryptographically stronger, so it is reserved for the data that matters most
- Asymmetric crypto is faster, so it handles the high-volume bulk traffic phase
- Symmetric crypto can distribute its own key safely over an open network
What can an on-path observer still learn about a normal TLS 1.3 connection without breaking the encryption?
- Which site you are visiting, from the destination IP and cleartext SNI
- The full contents of the HTTP request body that is sent on to the server
- The symmetric session key, since it is transmitted during the handshake
- The username and password, which TLS sends in a separate cleartext field
You got correct