Hi Yoav,
On 28/01/2018, 19:38, "Yoav Nir" <ynir.i...@gmail.com> 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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
