TCP/IP and a TLS Handshake

In the four-layer TCP/IP model used here, application combines many functions associated with OSI’s upper layers; transport supplies protocols such as TCP; internet supplies IP addressing/routing; and link covers local delivery and the underlying network access. A five-layer teaching model may separate physical from link. Declare which model a diagram uses rather than marking every different layer count as inherently wrong.

TCP provides an ordered reliable byte stream between endpoints under its protocol, using sequence and acknowledgement mechanisms. IP supplies routed packet delivery, while the link protocol handles a hop. TLS adds authenticated encryption for an appropriate connection above its underlying transport. TLS does not replace every role of TCP/IP, and a TLS record is not necessarily identical to one packet.

Consider a simplified certificate-authenticated TLS 1.3 connection. ClientHello offers supported parameters and a key share; ServerHello selects parameters and supplies a corresponding share. An ephemeral key agreement lets both sides derive shared secret material without sending the secret itself as plaintext. The server then supplies encrypted handshake information including its certificate, a proof using its signing key and a Finished message.

The client checks the server’s certificate/identity and the relevant handshake proofs, then sends its Finished. Application traffic uses derived symmetric authenticated-encryption keys. This summary omits optional/resumption paths. The current October 2026 primary reference is RFC 9846, published in July 2026, which supersedes RFC 8446 while retaining TLS 1.3. Its requirements include not reusing KeyShare values across connections. A certificate can contain an RSA signing key without TLS 1.3 using RSA to encrypt a premaster secret; that older key-transport story must be labelled as a different protocol/version model.

Scroll the diagram to see the full view.

Suppose the requested name is lab.example but the connection presents a certificate valid only for another name. Encryption alone does not justify accepting that identity. The client needs a suitable chain of trust and identity/name checks; merely receiving a public key from an unknown peer does not prove it belongs to the intended service. In a diagram, show validation as a decision rather than an automatic success.

A correctly authenticated encrypted connection protects the channel under its assumptions. It does not prove that an endpoint’s statements are true, that downloaded code is harmless or that a compromised endpoint will protect decrypted data. SSL is historical terminology; identify the actual TLS model being taught. An exam explanation should connect the mechanism to confidentiality/integrity/authentication without claiming it solves every application security problem.

Attempt the task before opening its worked response. Record each change of state, explain the rule used, and check the result against the original requirements. Code examples labelled Python 3 use that language’s conventions; pseudocode states its own assumptions.