Where TLS Sits: Between TCP and the Application

TLS runs on top of a TCP connection and underneath the application protocol: the application hands its data to TLS, TLS encrypts it into records, and TCP carries the records like any other bytes. Because it sits between them, neither HTTP nor TCP needs to know TLS exists, and any protocol that runs over TCP can be protected by inserting it.

In terms of the layers, TLS does not fit neatly in one. It provides security to the application, as layer 6 would, but runs as a library inside the application rather than in the operating system's network code.

Three facts follow from that position.

TLS is chosen by the application. A program uses TLS by opening its connection through a TLS library instead of a raw socket. Nothing in the network forces it; a server can offer the same service with and without TLS.

Its unit is the record. TLS splits the application's data into records of up to 16 KB, each encrypted and checked on its own. TCP then carries records as a byte stream, unaware of their boundaries.

Port 443 is a convention. HTTPS uses 443 and plain HTTP uses 80 so clients know what to expect, but TLS can run on any port. Other protocols have their own TLS ports, such as 993 for email over IMAP, while some, like SMTP between mail servers, upgrade an existing plain connection to TLS with a command.

The newest arrangement moves TLS. QUIC, the transport under HTTP/3, runs over UDP and includes the TLS 1.3 handshake inside its own, so encryption is not a separate layer on top but part of the transport. The guarantees are the same; the handshakes are merged, which saves a round trip.

So when a connection fails during setup, the layer matters: a failure in the TCP handshake is a network problem, while a failure after it, in the TLS handshake, is a certificate or configuration problem.