Summary

  • TLS 1.3 protects application content, one inner content-type octet and trailing zero padding together. The sender chooses the padding; the receiver validates and removes it before handing content upward. Padding changes representation, not application meaning.
  • A network capture can prove ciphertext length, direction and timing. It cannot directly divide the protected bytes into content, content type, padding and AEAD overhead. A larger record is therefore not proof of a larger application message.
  • Padding can coarsen length fingerprints and create cover traffic, but it does not erase timing, record count, responses, segmentation or application-processing leakage. Defensible claims require endpoint lengths, a versioned policy, negotiated limits and rejection evidence.

The arithmetic that crossed a layer boundary

The capture showed one outbound TLSCiphertext record larger than another by 512 octets. The report assigned those octets to the request body and inferred a user action. That inference would have been plausible only if the sender used a stable one-to-one mapping between application bytes and protected-record length.

It did not. The service had enabled block padding for Application Data. A callback inspected each plaintext length and added enough zero bytes to reach the next configured boundary. During idle intervals, another component could send an Application Data record with no content at all. Both records were genuine, authenticated TLS output. Neither made every observable byte part of an application message.

The error was not poor packet capture. It was an authority error. Network evidence was made to speak for endpoint semantics it could not observe.

Where content ends

TLS 1.3 forms TLSInnerPlaintext from three parts: content, a non-zero ContentType octet and a trailing run of zero bytes. The whole encoding is passed into record protection. The outer record type is the opaque value for Application Data, so an observer cannot recover the inner type by reading the header.

After successful AEAD decryption, the receiver scans backward within the returned cleartext. Zero octets are padding. The first non-zero octet is the inner content type. Everything before it is content. If the receiver finds no non-zero octet, it terminates the connection with unexpected_message.

That scan establishes a precise boundary at the endpoint. The application receives content after the padding is removed. Padding cannot add a method, credential, command or permission. It consumes protected-record space and network resources, but it carries no application instruction merely because it was authenticated with the content.

Cover traffic has a narrow grammar

TLS 1.3 permits Application Data with zero-length inner content. A sender can therefore create a plausibly sized protected record during a period with no application bytes. This can make the simple distinction between activity and silence less reliable for an observer.

The permission is content-type specific. An implementation must not send an empty Handshake or Alert message padded into a nonempty record. Those protocol messages have their own grammar and effects. The receiver must reject forbidden empty forms rather than treating padding as a licence to invent a message.

Cover traffic is also not proof of privacy. A peer response, processing delay, burst pattern or connection close may still distinguish real work from padding. A record with no application content can alter the observed distribution; it cannot guarantee that the distribution is uninformative.

Size limits remain real

Padding does not expand the TLS record budget. The complete TLSInnerPlaintext—content, inner type and padding—must remain within the protocol maximum. When peers negotiate record_size_limit, the smaller received limit applies to that complete plaintext as well.

This matters to policy design. A request for 1,024 padding bytes is not an unconditional order. The available space depends on the current content and negotiated limit. OpenSSL caps padding rather than allowing the record to exceed the maximum. An implementation may also fragment content differently before applying padding.

A wire-length comparison without the negotiated limit and fragmentation decision is incomplete. The same application message can become several records, one record, a padded record or a record capped below the requested boundary. The outcome belongs to running state, not to the padding policy name alone.

A mechanism is not a policy

The current TLS 1.3 specification provides the mechanism and intentionally leaves padding selection outside its scope. It does not prescribe a universal block size, probability distribution or cover-traffic schedule. Applications may sometimes be better placed to pad their own data because they know which fields and message boundaries are sensitive.

OpenSSL exposes this division directly. Its default is no record padding. Operators can set block padding or install a callback invoked for each TLS 1.3 record before encryption. Configuration can use one block size for Application Data and another for Handshake and Alert messages. A callback can also prevent kernel TLS from being used on that connection.

GnuTLS exposes per-send padding and lets applications ask whether length hiding is available. These APIs prove that a control surface exists. They do not prove that a particular process enabled it, which policy ran, or how many bytes were applied.

Constant-time removal does not make the application constant-time

Padding is encrypted, but its removal can still affect processing time. GnuTLS offers GNUTLS_SAFE_PADDING_CHECK to reduce leakage from pad-length-dependent processing and states that the option carries a performance cost.

The boundary continues above the library. After padding is removed, the application may parse, allocate, query storage or generate a response according to the real content. Those data-dependent actions can expose timing even if TLS record processing is constant-time.

The TLS specification therefore describes traffic analysis as an open system problem. Length padding can make one signal coarser. A fully constant-time endpoint would require cooperation from the higher-level protocol and application, while robust cover traffic adds delay and volume. “Padding enabled” is not a complete privacy property.

Composition decides where to pad

Application profiles use the mechanism for different purposes. EAP-TLS 1.3 recommends record padding to reduce leakage from certificate sizes. ECH separately pads the encoded inner ClientHello and identifies later encrypted handshake messages whose sensitive fields may need TLS record padding. The target and layer are explicit in both cases.

HTTP/3 warns that application frames, reserved frames and transport padding have different granularity, loss behavior and control. QUIC uses TLS handshake messages but does not carry ordinary TLS records on the wire. A TLS record-padding control cannot be projected automatically onto QUIC packet padding.

The contrast becomes stark with TLS integrity-only cipher suites. They can preserve the record structure and its integrity, but padding does not obscure plaintext size when confidentiality is absent. The privacy claim depends on encryption, policy and surrounding behavior, not on zero bytes alone.

What an observer may claim

A passive capture may reliably record endpoints, direction, time, ciphertext length, packetization and retransmission. With protocol context, it may also identify connection phases. It cannot directly observe the decrypted inner type, content length, pad length or application meaning.

The safe claim is bounded: “The endpoint emitted a protected record of N octets at time T.” An endpoint trace can extend it: “The process supplied C content octets, selected policy P version V, applied Z zero bytes, produced inner length I and ciphertext length N under limit L.”

Only the joined record supports a causal account. If policy provenance is missing, an investigator may compare length distributions and form a hypothesis. It should not promote the difference between two ciphertexts into a user action, object size or command.

Evidence that can survive an incident

Record connection identity, direction and sequence; TLS version and protection mode; inner content type; content length before padding; requested and applied pad length; final inner and ciphertext lengths; negotiated record limit; fragmentation; library version; kernel-TLS state; and padding-policy revision.

Measure bandwidth, latency and CPU costs beside the privacy target. Track size buckets, timing buckets, response correlation and cover-traffic ratio rather than reporting one aggregate byte overhead. Separate Handshake, Alert and Application Data policy.

Retain negative evidence. Test a cleartext containing only zeros, forbidden empty Handshake and Alert messages, oversized padding requests and records beyond the negotiated limit. Verify the exact alert or local refusal. Then disable the policy and prove that its length distribution and callback activity disappear.

The most important field is the one the packet capture cannot supply: application-content length before padding. Without it, observable length remains network evidence, not application authority.

Sources