Transport Layer Security

## Start with the attacker Every security property is meaningless without the adversary it is stated against. TLS assumes an attacker with **full control of the network path**: it can observe every byte, drop packets, reorder them, alter them, inject its own, and replay anything it recorded. This is not exotic - it describes a hostile wireless access point, a compromised router or middlebox, a hijacked route, a DNS answer that sends you somewhere else, or anyone operating an intermediate network you traverse. What the attacker is assumed *not* to be able to do: break the cryptographic primitives, and compromise the endpoints. That second exclusion is not a technicality; it is the boundary of the entire protocol. ## The four properties **Confidentiality.** After the handshake, application data is encrypted under keys known only to the two endpoints, so the path sees ciphertext. **Integrity.** Every record carries authentication, so modification is detected. Crucially, the failure mode is to *terminate the connection*, not to repair or ignore. There is no partial trust: a record either verifies or the connection dies. Anyone reasoning about TLS should internalise this fail-closed behaviour, because it is the reason the protocol resists an active attacker rather than merely a passive one. **Freshness and ordering.** Record protection binds a sequence number, so a recorded record cannot be replayed later in the same or another connection, records cannot be reordered, and a truncated stream is detectable - the protocol has an explicit close notification so that 'the connection ended' can be distinguished from 'the attacker cut it'. Handshake nonces make each handshake unique, so a recorded handshake cannot be replayed to establish the same keys. **Authenticity of the peer.** The server proves it holds the private key corresponding to a certificate that some trust anchor vouches for, and that the certificate names the identity the client intended to reach. Client authentication is optional and symmetrical in mechanism. ## Why authenticity is load-bearing This is the point interviewers listen for. The other three properties are stated relative to *the peer you are talking to*. If you do not verify who that is, an attacker on the path simply terminates your connection, presents its own certificate, and opens a second connection onward. You get a flawless encrypted channel - to the attacker - and your client reports success. Encryption without authentication converts a passive eavesdropper into an active relay, and gives you no signal that it happened. So 'we use TLS' is not a claim about strength of encryption. It is a claim about identity verification; the encryption follows from it. ## What TLS deliberately does not protect - **The endpoints.** Malware on the client, a compromised server, or script injected into the page all operate at a level TLS never sees. Data is plaintext at both ends by design. - **Anything after arrival.** The protocol has no opinion about logging, storage, or which third parties the peer forwards data to. 'It was sent over TLS' says nothing about what happened next. - **Authorisation.** TLS can tell you *who* the peer is, and with client certificates, who the caller is. It never tells you what they are allowed to do. That is application logic. - **Metadata.** The destination address is visible, the sizes and timing of records are visible, and the volume and rhythm of traffic often reveals which page, which action, or which of a small set of messages was sent - traffic analysis is a real technique, and padding is only a partial answer. The name of the server requested during the handshake was historically visible in the clear; encrypting it is a separate, unevenly deployed mechanism. - **Availability.** An attacker who can modify traffic can always destroy the connection. Fail-closed integrity means tampering becomes denial of service, which is the correct trade but is still an outcome the attacker controls. ## Channel, not message: the hop-by-hop caveat TLS secures a *connection between two endpoints*. In real deployments there are usually intermediaries: a load balancer, an API gateway, a CDN, a service mesh sidecar. Each of those terminates one TLS connection and originates another. The properties hold on each hop independently, which means the intermediary sees plaintext and can alter it, and the origin server's authenticity is proven to the intermediary rather than to the client. Consequences worth stating: 'end-to-end encrypted' is a much stronger claim than 'TLS everywhere', and if you need a guarantee that survives an intermediary - that this specific payload came from this specific party and was not altered - you need message-level signing or encryption in addition, because the transport's guarantee stops at each hop. Likewise, an identity that a proxy asserts to the backend in a header is only as trustworthy as the proxy and the network behind it; it is not a TLS property. ## Summing up TLS answers: is this channel private, unmodified, in order, and connected to the party I named? It does not answer: is the party trustworthy, is the data safe once it lands, who may do what, and who can see that I am talking to them at all.