Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

[Bryan A Ford <[e-mail]>]

On 11/27/15 5:21 PM, Henrick Hellström wrote:
> On 2015-11-27 15:35, Bryan A Ford wrote:
>> The idea of encrypting TLS record headers has come up before, the most
>> important purpose being to hide record lengths and boundaries and make
>> fingerprinting and traffic analysis harder.
> 
> How, exactly, would this be significantly harder? The adversary will
> still be able to tell when, and how much, TCP/IP data is sent between
> the peers. If there happens to be a revealing TLS record boundary in the
> middle of a TCP/IP packet, it would seem to me there is an
> implementation problem rather than a problem with the abstract protocol.

There are a variety of reasons TLS segment boundaries can and often do
become desynchronized from TLS record boundaries, such as:

(a) if the TLS implementation happens to encrypt several consecutive
records in a buffer and sends them with one write() call for efficiency.

(b) if the kernel TCP stack's send buffer is already non-empty on write
(e.g., held back to to congestion or flow control) and the TCP stack
decides simply to append the newly-written data to the already buffered
data, the boundary between those wrotes need not appear as a TCP segment
boundary.

(c) quite a few middleboxes can and do silently re-segment TCP streams
obliviously to the content of that stream.  In particular this tends to
happen as an incidental side-effect whenever the middlebox interposes on
the TCP stream by "terminating" the TCP connection and transparently
forwarding the content to/from a second TCP connection.

Now, this doesn't mean that "incidental" desynchronization of TCP
segment boundaries from TLS record boundaries will by itself add any
kind of robust protection against traffic analysis.  To achieve that, we
would want to ensure that a burst of (say) multiple HTTP requests and
their responses over the TLS connection get merged together and then
transmitted as a uniform-length series of blobs.  A sufficiently careful
TLS implementation could potentially achieve this, but with TLS headers
sent in cleartext, the TLS implementation is the *only* entity in the
system that can provide any kind of traffic analysis protection.

With TLS headers encrypted, it becomes feasible for some (weak or
strong) traffic analysis protection to be introduced at multiple points:

1. The TLS implementation can do it, either way.

2. Even if the TLS implementation doesn't try to provide any traffic
analysis protection, the kernel's TCP stack could provide some
protection (either intentionally or unintentionally) simply by merging
together consecutive writes as discussed above, so that transmissions
are usually just bursts of MTU-sized TCP segments even if they hold many
varying-size TLS records.

3. Finally, middleboxes can (again either intentionally or
unintentionally) add traffic analysis protection by re-segmenting TCP
traffic.  Corporate network operators often already see NATs as a
security advantage because they obfuscate the source IP addresses of
connections coming from the private network.  If TLS 1.3 encrypts its
record headers, then network operators and the middleboxes they deploy
will similarly be able to add traffic analysis protection "in the
middle" by re-segmenting TCP streams (which many of these middleboxes
may already be doing anyway), and whatever protection this provides will
apply to automatically to *all* TLS 1.3 traffic crossing that middlebox,
even if few or none of the actual TLS 1.3 endpoint implementations know
or care about traffic analysis protection.

In short, leaving TLS headers in cleartext basically hands any
eavesdropper a huge information side-channel unnecessarily and precludes
anyone *but* the TLS implementation itself from adding any traffic
analysis protection into the system.  Encrypting TLS headers appears to
cost practically nothing (at least if done as I've proposed), and it
allows traffic analysis protection (whether weak or strong, intentional
or unintentional) to be introduced at multiple points: e.g., by TLS
itself, or by the TCP stack, or by middleboxes.

Cheers
Bryan