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

["Fossati, Thomas (Nokia - GB/Cambridge, UK)" <[e-mail]>]

Hi Yoav,

On 28/01/2018, 19:38, "Yoav Nir" <[e-mail]> wrote:
> > 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. 
	
Thanks a lot for the very instructive info.

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

So, if I read you correctly, in terms of overriding length's MSB both 1
and 3 are safe places - as long as we apply the new semantics only after
handshake has completed.

2, is either "easily" fixable via a configuration change to fall back to
one of 1 or 3, or completely unfixable - the path is totally broken for
DTLS anyway because this is how the policy maker has decided.

Cheers, t