Application Data Protocol

In short: The TLS sub-protocol through which, after the handshake has been completed, the actual application data (e.g. HTTP requests) is transmitted in encrypted form.

In more detail: As soon as the handshake has been completed and the session key established, all further data of the connection is packed as “application data” via the TLS record protocol, encrypted and transmitted. Nothing of this is visible to the application layer above (e.g. HTTP) — it only sees a normal, but encrypted, connection.

In Depth

The path from plain text to encrypted packet

After the handshake, a TLS connection switches to the “application data” state — from this point on, every single data packet goes through the same sequence: encryption with the negotiated session key, appending a message authentication code (MAC) or auth tag for the integrity check, packing into a TLS record and sending over TCP.

Plain text (e.g. HTTP request)
  -> encryption with the session key (e.g. AES-256-GCM)
  -> append MAC/auth tag (integrity protection)
  -> TLS record header (type 23 = application data, length)
  -> send as TCP payload

Transparency for the application layer

The decisive point: for the application using TLS (e.g. a web browser speaking HTTP over HTTPS), this is completely transparent — it writes and reads completely normal bytes without knowing anything itself about encryption, records or session keys. This is the core advantage of the layered model: HTTP doesn’t need to know anything about cryptography, TLS doesn’t need to know anything about HTTP. This separation allows practically any protocol to be run “over TLS” — HTTPS (HTTP over TLS), but equally SMTPS, IMAPS, FTPS or even arbitrary TCP-based protocols, without them having to change anything about their own logic.

Record size and fragmentation

Records also have a fixed maximum size (16 KB, 2^14 bytes according to the TLS specification) — larger amounts of data (e.g. a large file) are therefore automatically split into several application data records, each encrypted individually and given its own MAC. This fragmentation has practical security implications: with HTTPS connections that were compressed and encrypted at the same time, the size of individual records could in the past allow conclusions to be drawn about the content (see the CRIME and BREACH attacks, which exploited compression BEFORE encryption to gradually guess secret tokens from the response length) — modern servers therefore disable TLS compression by default.

0-RTT data in TLS 1.3

TLS 1.3 additionally introduced so-called “0-RTT” data (zero round trip time): when reconnecting to a server that has already been visited before, the client can already send application data with the very first message, even before the handshake has formally been completed — this saves a complete network round trip and noticeably speeds up page loads. The trade-off: 0-RTT data is vulnerable to replay attacks (an attacker can record the very first message and send it again later), which is why servers typically only allow 0-RTT for requests without side effects (e.g. GET requests, no payment transactions).

How it differs from other TLS sub-protocols

Application data is one of four TLS sub-protocols (alongside the handshake protocol, change cipher spec protocol and alert protocol) — all four use the same record layer mechanism for packing, but differ in the record type byte, which tells the recipient how to interpret the content.

See also: TLS Record Protocol, Handshake