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

From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <[email-masked]>
Date: Sat, 27 Jan 2018 16:30:04 +0000

Hi TLS middle-box/middleware folks,

If length's MSB in a D?TLS{Ciphertext,Plaintext,Compressed} record is
set, how does your software react?

Is it going to drop the session/record or not bothering at all?

I'm trying to understand a bit better whether and when it'd be safe to
grab that bit and give it new semantics (e.g., for signalling the
presence of a DTLS connection-id, an ext-header, or anything else
really) and your answers would help shedding some (*) light on the
matter.

Based on previous experience on similar (but not identical) changes to
the record format, Adam ([1], [2]) suggested that this bit is likely to
have already ossified in TLS, whereas DTLS might be still OK.  So, I'm
curious to hear from those who own the boxes' logics if they share the
same opinion - in particular if DTLS is in better shape than TLS?

Thanks in advance for your time.

(*) I'm pretty sure not every TLS middle-box vendor on earth is
subscribed to this list and, even among those who are, not everyone
might be willing or able to share this information with the wider
community.  This is to say that I'm aware of the limited value a poll
like this has, but I'm not in a position to do a large-scale measurement
campaign at the moment, so better start from somewhere... OTOH, I think
there is a valuable discussion to be had in cases like this with folks
that don't own the endpoints but are going to (or have already) put
their logics on the e2e path, so hopefully I'm not wasting everyone's
time :-)

cheers, t

[1] https://www.ietf.org/mail-archive/web/tls/current/msg25299.html
[2] https://www.ietf.org/mail-archive/web/tls/current/msg25304.html

---

From: Yoav Nir <[email-masked]>
Date: Sat, 27 Jan 2018 21:31:36 +0200

> On 27 Jan 2018, at 18:30, Fossati, Thomas (Nokia - GB/Cambridge, UK) <[email-masked]> wrote:
> 
> [2] https://www.ietf.org/mail-archive/web/tls/current/msg25304.html <https://www.ietf.org/mail-archive/web/tls/current/msg25304.html>

Hi, Thomas.

I don’t work for a middlebox vendor anymore, although I did only 8 months ago. This answer is not based on recently looking at code.

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.

HTH

Yoav

---

From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <[email-masked]>
Date: Sun, 28 Jan 2018 10:19:32 +0000

Hi Yoav,

Thanks for the answers - much appreciated.

On 27/01/2018, 19:31, "Yoav Nir" <[email-masked]> wrote:
> The length field is byte-aligned. So any implementation of a TLS
> parser or TLS proxy will do one of two things:
> 
> 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.
> 
> 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.

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

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?

Cheers and thanks again

---

From: Yoav Nir <[email-masked]>
Date: Sun, 28 Jan 2018 21:38:04 +0200

Hi, Thomas

Inline

> On 28 Jan 2018, at 12:19, Fossati, Thomas (Nokia - GB/Cambridge, UK) <[email-masked]> wrote:
> 
> Hi Yoav,
> 

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.

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

> 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

---

From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <[email-masked]>
Date: Mon, 29 Jan 2018 10:04:01 +0000

Hi Yoav,

On 28/01/2018, 19:38, "Yoav Nir" <[email-masked]> wrote:
> 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. 
> 
> > 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?
> 
> 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