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

[Jacob Appelbaum <[e-mail]>]

On 12/2/15, Mike Copley <[e-mail]> wrote:
>
> On 2/12/2015, at 1:38 pm, Yoav Nir <[e-mail]> wrote:
>
>>
>>> On 2 Dec 2015, at 2:59 PM, Jacob Appelbaum <[e-mail]> wrote:
>>>
>>>
>>>> These are corporate
>>>> firewalls. When it comes to filtering HTTPS connections, firewalls have
>>>> three ways to classify the connection:
>>>> 1. Look at the SYN and SYN-ACK packets. Make decisions by IP addresses.
>>>> 2. #1, and additionally follow the stream looking for certain patterns.
>>>> 3. Full “TLS proxy”.
>>
>>>> Whether they are relevant stakeholders or not is to me the same question
>>>> as
>>>> whether the network administrator in a corporate environment is a
>>>> relevant
>>>> stakeholder. We just make the middlebox that they deploy.
>>>
>>> That is a kind of goal post shifting but seeminly weirdly not
>>> relevant, if I understand. If it won't trouble the middle box, it
>>> doesn't sound like the network administrator will have troubles.
>>>
>>> It will however reduce off-path reassembly to technique #1 from above
>>> and #2 will be partially eliminated and #3 isn't an option for that
>>> attacker anyway.
>>>
>>> We are working on solutions to #1, TLS 1.3 should reduce and if
>>> possible, eliminate #2, and #3 is something that should require
>>> consent of the user in question. Without consent, TLS 1.3 should hard
>>> fail closed as a security measure.
>>
>> A TLS proxy requires user consent (or at least device administrator
>> consent) with TLS 1.2. TLS 1.3 does not change that.
>
> With SNI it’s possible to operate a transparent TLS proxy without the users
> consent. The proxy only has visibility of the SNI hostname - no user data
> (source: the company I work develops routers with such a proxy).

Yes, we use that for a pluggable transport (
https://trac.torproject.org/projects/tor/wiki/doc/meek ) to bypass
such proxies - connect to google.com, use http header to route to
blocked.com, and so on.

> It’s quite
> useful in hotspot/public wifi environments where making policy decisions
> based on hostname is more than sufficient, and explicit user configuration
> of proxy settings is a non-starter.

That is an attack in my book and public hotspots that do MITM are also
a problem that we need to solve. It is partially solved with WISPr
XML, I think. Though everything in this space is awful because it
breaks everything by default while a system thinks it is online.

> As long as the SNI data is still
> available in the clear, encrypting subsequent headers won't impact the
> ability for our particular proxy to operate, as it’s just a generic TCP
> relay agent at that point.

I hope that we'll hide the SNI data by default and I understand that a
discussion about encrypted SNI is currently scheduled for some point
in the future.

> With all that being said, I think the concerns about length hiding are
> better addressed through other means rather than header encryption. Not sure
> if this is the right place to consider, but would DTLS 1.3(?) be able to
> encrypt headers and still handle packet loss and re-ordering? If DTLS needs
> cleartext headers, would it be better to advise one approach for both
> protocols?

I'm pretty sure that encryption is the only way to "hide"  the data we
want to hide...

All the best,
Jacob