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

[Yoav Nir <[e-mail]>]

> 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”.
>> 
>> 
>> Each of these is “heavier” in amount of resources that it consumes and in
>> the amount of breakage that it might introduce than the one before it, so
>> you only use a higher-numbered way if the lower-numbered way does not give
>> you the results you need. Specifically for #2 which is the one we’re
>> concerned about, there are very few attacks that can be detected by #2 that
>> cannot be detected by #1. I asked someone who does work on these
>> “protections” as we call them, and she told me that only two or three
>> protections require following the stream that do not require proxying, and
>> those were turned off in the default and recommended profiles. So at least
>> with a Check Point firewall, mostly you would not get breakage if record
>> lengths were encrypted, but someone making a client or a server cannot
>> assume that all paths will be free from such inspection. Also, there are
>> many firewall vendors and one is installed in most corporate environments.
> 
> That sounds like you're saying that the vendor you represent won't
> have issues and that it isn't a problem. Unless I misunderstand,
> you're claiming a concern and you've just cleared up that concern. So
> we can move on with Bryan's proposal?

To be clear, I don’t represent anybody. If I did, I would have to clear this mailing list message with a corporate lawyer and PR department.

I don’t think Bryan’s proposal will hurt the capabilities of a Check Point firewall, and it will make life difficult for me as a developer no more than it will make life difficult for developers of OpenSSL, NSS, SChannel, or any of a dozen other TLS implementations. I don’t know about the other IDS/IPS/Firewall devices.

>> So at least one vendor is listening in on this list, and I have a good hunch
>> that at least Cisco, Blue Coat and several others are on this list as well.
> 
> I'd love for Blue Coat to step up and talk about how this is similarly
> not a problem or how it is a problem for their illegal surveillance
> business in Syria, where they've been caught selling surveillance and
> censorship gear. I suspect they won't say much but we can hope, right?

I suspect that the Blue Coat people on this list do not represent their employer either.

>> 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.

>>> For example, do we really care what sandvine or xkeyscore or narus or
>>> similar vendors think? I think the answer is no. They're still going
>>> to do extremely powerful traffic analysis and the more information TLS
>>> leaks, the more they will use it to degrade the security of TLS for
>>> all users. It may be that they will be full, on path, attackers and
>>> yes, in some cases, they can do different more powerful attacks.
>>> Again, we should treat that as a negative thing and make it as hard as
>>> is possible.
>>> 
>>>> 
>>>> If enough middleboxes block TLS 1.3, the browsers will implement a
>>>> downgrade
>>>> dance. If they do that, attackers will be able to exploit the downgrade
>>>> dance. I don’t think the net effect is better security. We’d be far
>>>> better
>>>> off writing a separate document on how to use the padding feature that
>>>> is
>>>> already in 1.3 to mitigate traffic analysis without actually flooding
>>>> your
>>>> Internet connection. Splitting records and padding a few can be more
>>>> effective than masking the length bits.
>>> 
>>> Censors are going to perform surveillance and then censor; TLS 1.3
>>> should treat surveillance as a security issue and censorship as an
>>> attack. It may be that we can't stop certain kinds of on path attacks
>>> but man on the side seems nearly entirely do-able. I mean aside from
>>> the TCP reset issues do to layer violation concerns. At least we'll
>>> have DTLS, which won't suffer from such a trivial denial of service...
>>> right?
>> 
>> Or just use IPsec (I did say I’m no that side of the building…)
> 
> How well will IPsec deal with such an adversary? I think it is
> instructive at all the ways that a protocol won't compose cleanly with
> something like Tor, as well as how many distingusihers exist for
> technique #2 above. It is very frustrating because yes, it would be
> nice if we could just use IPsec. That is however nearly a total lost
> cause with regard to surveillance and censorship issues. I once talked
> to a Narus vendor who made some amazing claims about traffic analysis
> on IPsec - I'll try to dig up some documents.

IPsec has had a lightly-implemented TFC feature since RFC 4301. Without it a packet of IPsec is the same size as the original plaintext packet + a constant overhead rounded up to 4 bytes. So you could do as much traffic analysis on non-TFC IPsec as you could on the plaintext.

Yoav