What TLS Protects—and What It Still Exposes
For PromptEcho, TLS 1.3 is not the defeated system; it is the boundary that tells us what remains available to an observer after encryption succeeds. This chapter focuses on the TLS handshake and record layer, and on the practical judgment they support: seeing the size and order of encrypted records is not the same as reading their contents, but it can still provide metadata that an application-specific attack may use. Understanding that distinction keeps the LLM result in proportion. The attack is a traffic-analysis problem built above a functioning cryptographic channel.
Security is more than secrecy
TLS is designed to create a secure channel between two endpoints over an untrusted network. Its first task is the handshake. The client and server negotiate protocol parameters, authenticate the server, optionally authenticate the client, and establish shared traffic keys. Once that state exists, application data moves through a separate record protocol. The handshake creates the conditions for protection; the record layer repeatedly applies those conditions to the data stream.
That separation matters because the protections have different meanings. Authentication gives the client confidence about which server is at the other end. Confidentiality prevents a network observer from seeing the application bytes in their original form. Integrity makes unauthorized modification detectable. None of those properties says that the observer sees no structure at all. A channel can hide a byte sequence while still exposing how much data was sent, when records appeared, or how the sender divided the stream.
RFC 8446 states this boundary directly: TLS confidentiality does not hide the length of the data it transmits. The statement is not an admission that encryption is weak. Length is not normally needed to decrypt a ciphertext, and the protocol’s primary confidentiality guarantee concerns the content itself. But length can matter to a different class of analysis. If the same application repeatedly turns different messages into measurably different traffic shapes, an observer may learn something without recovering the underlying bytes.
The record layer is the mechanism through which this shape appears. It breaks information into records, each protected under traffic keys. A record has an outer header containing a content type, a legacy version field, and a length, followed by the protected body once encryption is active. For TLS 1.3 application data, the outer type is presented as application_data; the actual inner type is recovered only after decryption. The header therefore does not reveal whether the protected body contains a particular sentence, but it does tell an observer how long the following encrypted record is.
That visible length is not a token count. It includes protocol effects as well as application content. The observer sees a transport-layer measurement whose meaning depends on what the application put into the record, how the endpoint framed it, and what cryptographic expansion was added. Treating the number as plaintext would be a category error. Treating it as entirely meaningless would be another. The correct question is whether the surrounding system makes the number correlate with a property of the hidden content.
A useful abstraction is to imagine a sequence of protected records rather than one encrypted file. For each record, the wire length reflects a content portion, an inner type byte, optional padding, and the AEAD expansion. If the service places a response event into the content portion with little extra variation, changes in the event can move the outer length. If the service combines several events, the same observation represents their total. If it pads each record to a common size, the relationship weakens. The TLS layer does not decide which of these application behaviors occurs; it faithfully protects whatever structure the endpoint gives it.
This also explains why record counts can carry a different signal from record sizes. Two responses with the same total number of application bytes can be divided into different numbers of records, exposing differences in buffering or delivery policy. Two responses with the same number of records can have different lengths. A passive observer can combine both dimensions—how many protected units appeared, in what order, and how large they were—without knowing what any unit says. PromptEcho’s attack is built on the possibility that this sequence is stable enough across an API’s interactions to be modeled.
The cryptographic contribution is usually the least interesting part of that model. AEAD adds a known kind of expansion and authenticates the protected structure; it does not randomize the length into an unrelated value. Padding is the variable that can deliberately add uncertainty, but only an endpoint policy can choose it. As a result, a service’s security posture depends not just on whether it negotiated TLS 1.3, but also on whether its response serialization and padding policy make the resulting record sequence independent of sensitive content. That is an application and deployment question layered on top of a sound protocol.
The distinction becomes clearer when separating a TLS record from a network packet. TLS operates over a reliable, in-order byte stream. A record can be carried inside one transport segment, or a transport segment can contain parts of more than one record. If a record is large enough, the network can split it across several segments. Conversely, application data may be divided across records or coalesced into one record. A capture tool that reports packet sizes is therefore not automatically reporting record sizes, and a record size is not automatically reporting one application message.
This is one reason the PromptEcho paper treats extraction as an empirical step rather than assuming a universal formula. Its observer must identify the response flow, distinguish relevant records from surrounding protocol material, and account for the service’s framing. TLS supplies a stable envelope, but the application decides how much response data enters each record. The transport view is useful only after those layers are kept separate.
The record boundary also explains why integrity does not solve the problem. Integrity protects the relationship between ciphertext and the endpoint’s expected plaintext. An observer who changes the record will normally cause decryption or authentication to fail. But an observer who only measures the record has not altered anything. The record can be perfectly authentic and still reveal its outer size. Confidentiality and integrity prevent content disclosure and undetected tampering; they do not automatically provide resistance to every inference based on legitimate metadata.
The observer in this picture has less power than either endpoint. They do not possess the traffic keys, do not see the inner content type, and cannot decide how the server interpreted the prompt. Their information is a sequence of externally visible records. That sequence becomes a side channel only if the application’s behavior gives it a repeatable relationship to the response.
An encrypted record still has a length equation
TLS 1.3 makes the relationship between content and record size more precise. Before protection, an application fragment is represented as content. When the endpoint encrypts it, TLS constructs an inner plaintext containing three conceptual pieces: the content, an inner content-type byte, and an optional run of zero-valued padding bytes. An AEAD algorithm then encrypts and authenticates that structure. The resulting ciphertext is placed after an outer header whose length describes the encrypted record.
In simplified form, the observable encrypted length is the application content length plus the inner type byte, any selected padding, and the cipher’s expansion. The exact expansion depends on the negotiated AEAD algorithm, but it is not a secret variable that restores the plaintext. It changes the size in a protocol-defined way. An observer cannot subtract the known cryptographic contribution and thereby obtain the message text; at most, they may obtain a more useful estimate of how much application material was carried, provided the other framing components are understood.
The inner type is deliberately protected. After encryption, an outside observer sees the generic outer application_data type rather than whether the record contains application content or another protected TLS message. This is an important confidentiality improvement in the protocol’s wire appearance, but it does not remove the length field. The encrypted body remains opaque while its container retains a measurable extent.
Padding is TLS’s explicit answer to this residual signal. An endpoint may append arbitrary zero padding inside an encrypted record, subject to the record-size limits. The receiver removes it after successful decryption by scanning backward to the nonzero inner content type. Because the padding is inside the authenticated encryption, an observer cannot tell which bytes are meaningful content and which are padding merely by inspecting the ciphertext. If padding is chosen well, two application messages with different content lengths can produce less distinguishable record sizes.
The phrase “may pad” is doing important work. RFC 8446 defines the mechanism but does not prescribe a general padding policy. An implementation can send an unpadded record, which is simply a record with zero padding. It can choose a fixed amount, a variable amount, or a policy tied to some application condition. The protocol also permits zero-length application content, which can support cover traffic when the presence or absence of activity is sensitive. But a capability in the standard does not tell us whether a service uses it, how much it uses, or whether its policy is strong against a particular inference method.
Padding therefore changes the analysis rather than ending it by definition. Constant padding can make small content differences less visible while still leaving larger differences. Padding to a common maximum can reduce correlation more strongly but consume more bandwidth. Randomized padding can prevent an observer from learning one stable offset, yet the distribution of sizes may remain informative if it is too narrow or predictable. These are policy questions, not consequences that TLS selects automatically. The PromptEcho paper’s proposed defenses—dynamic padding, randomized obfuscation, and coarser aggregation—belong to this deployment layer.
Consider two application fragments that differ slightly in length. If both are padded into the same size class, the observer loses the ability to distinguish that small difference from the record alone. But a longer fragment may cross into the next class and become visible again. Padding policy must therefore be evaluated against the distribution of the protected data, not merely switched on. The same principle applies to random padding: randomness helps when it is large and unpredictable relative to the content variation an attacker is trying to model, but a narrow distribution can leave useful statistical structure.
Cover traffic and empty application-data records address yet another observable: whether activity occurred at all. They can make an idle period look more like an active one, but they add traffic and require endpoints to agree on behavior. None of these choices changes the server’s generated text or the strength of AEAD. They change the relationship between that text and the sequence an outside observer measures. That relationship—not the existence of an encrypted tunnel by itself—is the object a traffic-analysis defense must manage.
There is also a distinction between TLS-layer and application-layer padding. The TLS record mechanism can inflate the protected record, but an API can also alter how response content is serialized and batched before TLS sees it. If a service places several response events into a larger, less predictable unit, it changes the application’s contribution to the record. If it delays transmission until more content is available, it changes timing and user experience as well. The security benefit and the product cost depend on where the relationship between content and delivery is being broken.
This is the point at which a generic TLS explanation must stop. The RFC establishes that record length is not automatically hidden and that padding is available. It does not establish that every LLM provider exposes a useful token-length sequence. That second claim depends on service-specific behavior: tokenization, streaming format, buffering, fixed metadata, and the absence or weakness of additional obfuscation. PromptEcho’s contribution is to show how, under the services and traffic conditions it measured, those application choices can preserve enough structure for semantic inference.
The transport layer has therefore given us a careful boundary. The network observer sees a protected sequence of records, not a readable answer. Optional padding can make the sequence less correlated with the answer, but the standard leaves the policy to the endpoints. The next question is higher in the stack: how does an LLM service turn generated tokens into chunks whose lengths remain related to the text, and how can an observer separate that variable content from the stable overhead around it?