Re: [TLS] A question for TLS middle-box/middleware vendors/implementers

[Yoav Nir <[e-mail]>]

Hi, Thomas

Inline

> On 28 Jan 2018, at 12:19, Fossati, Thomas (Nokia - GB/Cambridge, UK) <[e-mail]> wrote:
> 
> Hi Yoav,
> 
> Thanks for the answers - much appreciated.
> 
> On 27/01/2018, 19:31, "Yoav Nir" <[e-mail]> wrote:
>> The length field is byte-aligned. So any implementation of a TLS
>> parser or TLS proxy will do one of two things:
>> 
>> 1. Consider the MSB to be a must-be-zero bit and drop any length field
>> that has it set as faulty.
>> 
>> 2. Ignore text about limits on length and assume the record is that
>> big. Depending on what field that is, this may cause a drop on some
>> other sanity check.
>> 
>> As always there’s option #3 (crash), but the industry is getting
>> better at avoiding that.
>> 
>> You seem to want the behaviour that the middlebox masks out the
>> must-be-zero bits and considers only the relevant length bits. I don’t
>> think that would pass code review at my former employer.
> 
> What I was thinking was rather "once handshake is done and client has
> successfully passed the SNI checks, just blindly copy the byte stream
> across." I had this specific mental model (that of an HTTPS filter) in
> my head, which of course is just one of many.

When middleboxes just classify and route (at Check Point we called that “passive inspection” as opposed to “active inspection” which was a TLS proxy) then yes - as soon as the data becomes encrypted you either drop it or let it through. As this is much higher performance (a given piece of hardware can handle much more passive inspection that it can active inspection), it was preferred for domains that were considered low-risk. 

TLS 1.3 means that a passive proxy needs to make the decision earlier.

> If the use case is "check for data exfiltration or covert channels",
> then the box is probably going to be a fully-fledged interception proxy.
> In that case the parser can't be sloppy, and the bit will not go through
> unnoticed (as you correctly note above).
> 
> But - pardon a naive mind -  these look like the kind of boxes that you
> can't just switch on and forget about.  Instead, I'd imagine you need to
> keep their release cycle aligned with that of the endpoints, especially
> browsers, which tends to be pretty aggressive.  (But yes, one thing is
> the vendor release cycle, and a completely different one is the network
> operator's upgrade schedule…)

Vendors release updates at a good pace, some through software upgrades and some through updating data files. An upgrade from supporting TLS 1.2 to supporting TLS 1.3 as a proxy usually requires a software upgrade. But the changes for passive proxy can be done through issuing an update to some regular expression or other rule. Typically customers buy a piece of software and subscribe to updates. 

The Internet is full of old versions because the administrators don’t don’t want to rock the boat or are content with a good, stable release, the same way that Windows 7 is still so popular. In some cases the middlebox vendor has gone out of business.

The Internet is also full of middleboxes where the subscription was allowed to lapse. It seems like carelessness. 

> Since you are here, and you have amassed a considerable amount of wisdom
> in this space, I have a further question: Is, in your opinion, DTLS in a
> better spot than TLS WRT the use of that bit?

With a firewall that doesn’t know about DTLS, there are three choices:
1. Allow all the DTLS
2. Block all the DTLS
3. Write a regular expression (or equivalent) that will check the DTLS handshake for sanity.

If DTLS becomes popular, newer versions of firewalls will be able to handle them the same as they do TLS. For now, DTLS is seeing little use.

Yoav