Securing TCP Connections (SSL)

Computer Network & Network Security System — Network Security, NEC licence examination syllabus (Nepal Engineering Council).

Securing TCP Connections: SSL/TLS

The padlock icon in your browser is the visible tip of a much bigger process.

🤝 SSL/TLS Handshake

PurposeBefore any encrypted data flows, client and server must agree on encryption algorithms and securely exchange keys.

Key stepsServer presents its certificate (proving its identity), client and server agree on a shared symmetric session key (often using asymmetric crypto just for this exchange step), then all further data uses fast symmetric encryption.

Once the handshake completes, the record protocol takes over — it's the part that actually fragments, compresses, and encrypts the real application data for the rest of the session.

💡 One-liner: "Why does SSL/TLS use asymmetric crypto only during the handshake, then switch to symmetric?" → Exactly the same reasoning as PGP — asymmetric crypto safely exchanges a key, then fast symmetric crypto handles the bulk data.

What stops an attacker presenting their own certificate

"The server presents its certificate, proving its identity" leaves the important question unanswered. Anyone can generate a certificate saying they are your bank. What makes one believable?

A certificate is only trusted because it is signed by a certificate authority, whose own certificate is signed by another, up to a root certificate that your browser or operating system already holds. Verification walks that chain: each certificate's signature is checked using the public key of the one above it, until a root you already trust is reached. An attacker can produce a certificate, but cannot get it signed by a root your machine trusts.

🔗 What the browser checks

Signature chainEach certificate is validly signed by the next one up, ending at a trusted root.

NameThe certificate is issued for the domain actually being visited — the check that defeats a genuine certificate for a different site.

Validity datesNot expired, not used before it becomes valid.

RevocationNot withdrawn by its issuer since being issued.

💡 So a browser warning is not the encryption failing — the traffic may be perfectly well encrypted. It means identity could not be established, so the encryption might be with an impostor. Encrypting to the wrong party is no protection, which is why the warning is as severe as it is.

What the handshake achieves, beyond the key

Three things are settled before any application data moves.

🤝 In the handshake

Cipher negotiationClient and server agree the strongest algorithms they both support, which is how the protocol evolves without breaking older clients.

AuthenticationThe certificate chain proves the server is who it claims. Client certificates exist but are rarely used on the web.

Key agreementA session key is established for the fast symmetric encryption that follows.

The negotiation step carries its own risk: an attacker who can tamper with the handshake might force both sides onto the weakest algorithms they support — a downgrade attack. Modern versions defend against it by including a hash of the entire handshake in the final messages, so any alteration is detected before data flows.

Why the record protocol adds a MAC

The record protocol encrypts application data, and it also attaches a message authentication code to every record. Encryption alone hides content but does not prevent an attacker altering ciphertext in transit; the MAC makes any modification detectable.

💡 Confidentiality and integrity are separate properties needing separate mechanisms — the same lesson as digital signatures, where signing gives integrity and authenticity but not confidentiality. Neither implies the other.

Syllabus points

SSL/TLS handshake
Record protocol

Create a free account to tick topics off, take notes as you read, watch the video lessons and get a day-by-day study plan built around your exam date.