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

[Watson Ladd <[e-mail]>]

On Sat, Nov 28, 2015 at 1:08 PM, Tony Arcieri <[e-mail]> wrote:

> On Sat, Nov 28, 2015 at 10:05 AM, Roland Zink <[e-mail]> wrote:
>
>> Am 28.11.2015 um 17:56 schrieb Henrick Hellström:
>>
>>> AFAIK, HTTP 1.1 browsers typically don't send a new request over an open
>>> connection, before it has received the response to the previous request. If
>>> that is the case, it is trivial to get the message lengths from the
>>> traffic, with or without encrypted TLS record headers. IOW you gain nothing
>>> by encrypting the length fields.
>>>
>>> I think this is what browsers do by default. For HTTP2 this should be
>> different.
>
>
> This is HTTP/1.1 pipelining, which is supported by most browsers but
> typically disabled by default as most servers don't support pipelining
> correctly.
>

I think the above analysis is wrong. Consider a service written in Go using
the built-in TLS library. Then the number and sizes of writes is visible to
an attacker, which can reveal information about which branches were taken
and the data sent. That's not because the total size of the response
necessarily changes, but the sequence of writes taken to get there.


> --
> Tony Arcieri
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>


-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.