Subject: [TLS] Update on TLS 1.3 Middlebox Issues

From: Eric Rescorla <[email-masked]>
Date: Fri, 6 Oct 2017 13:16:37 -0700

Hi folks,

In Prague I mentioned that we were seeing evidence of increased
failures with TLS 1.3 which we believed were due to middleboxes. In
the meantime, several of us have done experiments on this, and I
wanted to provide an update.

The high-order bit is that *negotiating* TLS 1.3 seems to cause
increased failures with a variety of middleboxes (it’s generally safe
to offer TLS 1.3 to servers which don’t support it). The measured
incremental error rates vary quite a bit, ranging from minimal
(Facebook) to ~1.5% (Firefox) and ~3.4% (Chrome). Each of us is using
a slightly different methodology (organic versus forced traffic) and
different populations (mobile, desktop, enterprise, etc), but it does
seem like there is a nontrivial failure rate. At this point, we have
two options:

- Fall back to TLS 1.2 (as we have unfortunately done for previous releases)
- Try to make small adaptations to TLS 1.3 to make it work better with
middleboxes.

The Chrome team has been working on angle #2 and has been having
success with an approach of trying to make TLS 1.3 connections look
more like TLS 1.2. Their current experiments get them down to about 1%
incremental failures and they are currently measuring some changes
they hope will shave that down more. These changes are a bit annoying
but basically superficial; they do not affect the cryptography.

Separately, Firefox and Facebook have been experimenting with the new
content type described in PR#1051 (Google’s and Facebook’s results
conflict, so this is a bit of a mystery). We hope to have results from
both sets of experiments by end of October, at which point we should
be able to discuss the best way forward as a group.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 7 Oct 2017 01:01:57 +0000

Thanks very much for the update.

There is a third option, name the devices which are known to cause problems, and move forward with the draft as-is.

---

From: Carl Mehner <[email-masked]>
Date: Fri, 6 Oct 2017 22:27:22 -0500

I think this third option is a good idea, it's worked in the past with at
least 2 different load balancers and (to an extent) with a certain color of
proxy.

People that work in "Enterprises" do follow this list and can help open
tickets with vendors and get the work prioritized.

On Oct 6, 2017 8:02 PM, "Salz, Rich" <[email-masked]> wrote:

There is a third option, name the devices which are known to cause
problems, and move forward with the draft as-is.

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Hanno Böck <[email-masked]>
Date: Sat, 7 Oct 2017 09:17:20 +0200

Alternative proposal:

1. Identify the responsible vendors.
2. Tell all those vendors "You have 1 month to fix this. Fix it. Oh,
it's your customers who don't update? Seems you don't have any
reasonable update system. Call your customers, send some support staff
to them. Fix this. Now."
3. Call for a boycott of the vendors who are not able to fix this.

Seriously... If only 2 or 3 of the large companies that are involved
here would do this I am sure we don't have such problems any more in
the future.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: [email-masked]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 7 Oct 2017 12:57:23 +0300

> - Try to make small adaptations to TLS 1.3 to make it work better with

What you think is acceptable failure rate? That is, if we can't get
the rate below that, don't bother with adaptation?
 
> be able to discuss the best way forward as a group.

Has there been attempts at figuring out what exactly the middleboxes
are intolerant to?

Here are some candidates that come to mind:

1) Handshake seemingly cutting short (quite annoying to fix)
2) Server version seemingly ahead of client version (annoying to fix)
3) Second byte of ServerVersion is >3 (annoying to fix).
4) Unknown extension negotiated (very annoying to fix).
5) Two missing fields in TLS 1.3 ServerHello throwing off parser (not
   difficult to fix)
6) First byte of ServerVersion != 3 (no issue, non-representative
   test, as per -21, the final TLS 1.3 will have ServerVersion 3,4).

I guess the reason Google's and Facebook's results conflict is that
they tend to hit different kinds of middleboxes. I guess Google
hits more enterprise middleboxes (more strict) and Facebook hits more
carrier middleboxes (less strict). 

This could explain the conflict, because if carrier middlebox loses the
handshake without parse error (which is what the Facebook's hack does),
it probably will let things through. Whereas enterprise middleboxes
tend to more deeply inspect the handshake and probably error out if the
handshake isn't as expected. Fooling the latter might not be easy.

Then there is the question what on earth are those carrier middleboxes
trying to do? Why they seemingly try to parse ServerHello? Looking at
the extension list, the only even remotely sensible to me candidates
are session resumption, certificate types and ALPN (and the latter two
are much more dubious than the first).

For more strict Enterprise middleboxes, parsing the ServerHello makes
some sense, even up to the point of failing on unknown extensions.

If one wants to do variant tests, I would try to test:

Variant 0) Stock TLS 1.2 (for baseline)
Variant 1) TLS 1.2 with unknown extension (no effect) negotiated.
Variant 2) TLS 1.2 ServerHello, with KeyShare extension and TLS 1.3
           ciphersuite, with rest of handshake from TLS 1.3.
Variant 3) Variant 2, but with ServerVersion of 3,x (x>3).
Variant 4) Variant 3, with the two dummy fields removed and server
           version of 3.4 (essentially final TLS 1.3 as of current
           draft).

-Ilari

---

From: Yoav Nir <[email-masked]>
Date: Sat, 7 Oct 2017 14:33:37 +0300

> On 7 Oct 2017, at 4:01, Salz, Rich <[email-masked]> wrote:
> 

+1.  I like this third option.

> reasonable update system. Call your customers,

Vendor: Hello customer. We have an update for you that will make TLS 1.3 work.

Customer: No way. We’re in the middle of the year-end processing. We’re not making any configuration changes until the second week of January.

Vendor: But it’s a simple fix. It will make things work better. You’ll need it for Chrome to work with Google.

Customer: What part of “not making any configuration changes” was not clear to you!?

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 7 Oct 2017 07:08:01 -0700

> the rate below that, don't bother with adaptation?

I'm not precisely sure. I think it would depend on the client profile, but
at this existing rate, Firefox, at least, would have to do fallback. That's
what Firefox Beta currently does.

> Has there been attempts at figuring out what exactly the middleboxes

Yes, there has been some of that, but mostly by the Google team and I don't
want to speak for them.

Best,
-Ekr

---

From: Nick Sullivan <[email-masked]>
Date: Sat, 07 Oct 2017 14:17:37 +0000

Yoav,

Let me make a correction to your scenario:. Instead of:
"You’ll need it for Chrome to work with Google."
it's:
"You’ll need it for Chrome to work with Google, Facebook, and most of the
10% of Alexa top million sites that are using Cloudflare."

TLS 1.3 (in on draft version or another) is very widely deployed on the
server side. Enabling it by default in a major browser would break enough
of the Internet that both middlebox vendors and enterprises/ISP who use
them will take notice.

The browser vendors will have to do their own calculus around whether or
not the ecosystem benefits of accelerating the deployment of TLS 1.3
compatibility by deploying no-downgrade TLS 1.3 defaults outweigh the
business costs associated with the potential harm to their relationships
with enterprises.

For example, Chrome has a history of making large bets that break a portion
of the internet in order to force ecosystem changes (see SHA-1, SSLv3).
However, these have been projects with gradual changes and long lead times.
Also, the failure rates introduced by such changes were well below 2% of
all connections. Furthermore, these changes typically revolved around
server changes (updating certs, changing configurations) not
software/firmware updates to devices.

I don't want to speak for browser vendors, but history suggests that Option
3) may not be a viable one for browsers with a significant market share.

Nick

On Sat, Oct 7, 2017 at 1:33 PM Yoav Nir <[email-masked]> wrote:

> Customer: No way. We’re in the middle of the year-end processing. We’re
> not making any configuration changes until the second week of January.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 7 Oct 2017 14:43:13 +0000

➢ I don't want to speak for browser vendors, but history suggests that Option 3) may not be a viable one for browsers with a significant market share.

They can do what they want, but if they’re “in the rough” on the consensus call, I hope they’ll go along.

As for yoav’s point about “not during Q4” freeze; that happens to both clients and servers :)

I ask that everyone who is involved in these “middlebox failure experiments,” collectively or individually, work on a presentation for Singapore.  Unless there are some big surprises, I am going to ask for a consensus call on just moving it forward.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 7 Oct 2017 07:44:23 -0700

> 10% of Alexa top million sites that are using Cloudflare."

Personally, if we can make the final version work better with a few
minor changes to negotiation we should, even if that means dropping
the version negotiation mechanism and using extensions instead. If we
end up needing more flights, that's going to be sad and we'll just
have to wait for QUIC.

Sincerely,
Watson Ladd

---

From: Richard Barnes <[email-masked]>
Date: Sat, 7 Oct 2017 10:57:15 -0400

On Oct 7, 2017 10:43, "Salz, Rich" <[email-masked]> wrote:

➢ I don't want to speak for browser vendors, but history suggests that
Option 3) may not be a viable one for browsers with a significant market
share.

They can do what they want, but if they’re “in the rough” on the consensus
call, I hope they’ll go along.

Rich, I think you may be forgetting that IETF standards are voluntary.
They may be in the rough with regard to Publishing an RFC, but if they
can't ship that RFC, they won't, and publishing an RFC that can't be
shipped doesn't do much good.

Better to take the time to figure out how to make this deployable (with a
blend of 1/2 and 3).   We're still a decade ahead of the 1.2 roll out
timeline.

--Richard

As for yoav’s point about “not during Q4” freeze; that happens to both
clients and servers :)

I ask that everyone who is involved in these “middlebox failure
experiments,” collectively or individually, work on a presentation for
Singapore.  Unless there are some big surprises, I am going to ask for a
consensus call on just moving it forward.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 7 Oct 2017 08:01:33 -0700

> end up needing more flights, that's going to be sad and we'll just

None of the changes anyone is contemplating involve more flights.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 7 Oct 2017 08:02:28 -0700

I suggest we not have this debate now. We'll have a lot more data towards
the end of the month and we can have an informed discussion then.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 7 Oct 2017 15:25:29 +0000

> I suggest we not have this debate now. We'll have a lot more data towards the end of the month and we can have an informed discussion then.

That is what I am asking for.  More information so that the entire WG can make an informed decision.  And I was only laying out an option that does not seem to have been considered before.

---

From: Jeffrey Walton <[email-masked]>
Date: Sat, 7 Oct 2017 11:33:33 -0400

> That is what I am asking for.  More information so that the entire WG can
> make an informed decision.  And I was only laying out an option that does
> not seem to have been considered before.

The group (or the IETF) might also consider a policy to answer Ilari
Liusvaara's question, "What you think is acceptable failure rate?"

That is a governance issue. It should probably be [nearly] written in
stone and applied equally to all problems and decisions.

As an example, the US's IRS used to have a policy to support any
browser with 3% market share or more. I don't know what it is
nowadays.

Jeff

---

From: Hanno Böck <[email-masked]>
Date: Sat, 7 Oct 2017 17:35:30 +0200

Hi,

On Fri, 6 Oct 2017 13:16:37 -0700

> - Fall back to TLS 1.2 (as we have unfortunately done for previous

Thinking about this I honestly hope nobody is considering this
seriously. This would be an unfixable security design flaw. And it also
quite significantly differs from previous fallbacks.

There were workarounds in the past for version intolerance by using
SCSV and early versions of 1.3 used some trick with the server random
value. However that was for nonconformant servers that allowed
conformant servers and clients to prevent downgrade attacks.

Such workarounds won't work if we talk about middleboxes, because
what's proposed here is to fallback to TLS 1.2 even if both the server
and the client speak TLS 1.3.

In other words: It's a proposal to make all security advantages of TLS
1.3 irrelevant, as we have a universal downgrade to 1.2.

Given that this would also mean there's no visible incentive to fix
things it would very likely mean keeping this broken workaround for
many years to come.

-- 
Hanno Böck
https://hboeck.de/

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 7 Oct 2017 08:35:35 -0700

On Sat, Oct 7, 2017 at 8:25 AM, Salz, Rich <[email-masked]> wrote:

>
>
> > I suggest we not have this debate now. We'll have a lot more data
> towards the end of the month and we can have an informed discussion then.
>
>
>
>
>
> make an informed decision.
>

I didn't intend to be arguing with you. I'm happy to present what I have in
Singapore and while I can't speak for others, I expect they would be as
well.

-Ekr

> And I was only laying out an option that does not seem to have been
> considered before.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 7 Oct 2017 15:55:37 +0000

> I didn't intend to be arguing with you. I'm happy to present what I have in Singapore and while I can't speak for others, I expect they would be as well.

*I* know you meant everyone else on this thread, and not me.

FB and Google folks, will you present at Singapore?

---

From: Adam Langley <[email-masked]>
Date: Sat, 7 Oct 2017 09:38:24 -0700

> 3. Call for a boycott of the vendors who are not able to fix this.

In the past, Chrome has both steam-rollered over intolerance issues
and used "naming and shaming" when it appeared useful.

Naming and shaming can be an effective strategy when there is a small
percentage of aberrant actors, but that doesn't appear to be the case
here. It's not a single vendor, it's several, and we likely don't have
a complete list because it's very difficult to get
vendor/model/version information from the field. These issues vary
across devices, across firmware versions (for which the active range
is large), and across configurations (similarly large).

As for the steam-roller: while /we/ may understand the issues in
sufficient depth to know where the fault lies, the operating heuristic
in IT is that the last thing that changed is to blame. That makes
steam-rollering expensive. Sometimes we do it anyway, but the levels
of breakage measured for the current TLS 1.3 wire-format are too high
to be viable. There would have to be a fallback, and fallbacks are
terrible. We've only recently gotten out of the last lot of them and
should not do that again.

I understand the share the justifiable anger at companies that are
making profits by handicapping the internet that they depend on; we
are paying their externalities right now. But the problem here is too
widespread for either of the above strategies to be effective.

We're still testing, but it appears that a few,
security-inconsequential changes to TLS 1.3 make it significantly more
viable to deploy. That has got to be preferable to behaviours like
fallback, which is very security-consequential. This has taken time
because getting good exposure needs changes to both our frontends and
to Chrome Stable, which makes the iteration time long. We can iterate
much faster with local middleboxes (and we've bought several), but the
diversity of firmware versions and configurations means that we can't
get great testing coverage from that approach.

This looks, overwhelmingly, like the best path for TLS 1.3. For the
future, I think we need to ponder changes in the way that we build and
defend protocols. I think that GREASE
(https://tools.ietf.org/html/draft-ietf-tls-grease-00) demonstrates
the sort of change in thinking that is needed, but that we need to go
further.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 7 Oct 2017 20:28:22 +0300

> get great testing coverage from that approach.

Yes, and with local testing, one can't get the relative importances
right, only to guide what to test on field.

And even in field tests, there is issue of survivorship bias. I think
that is the cause for seeming conflicts between the results.

And even if the changes might not be directly consequential to
security, the changes to get through some more annoying middleboxes
might be quite annoying to implement.

E.g. there probably are several different middeboxes that have a
configuration that actually checks that the handshake looks valid,
which includes checks for things like ChangeCipherSpec being
present in both directions, even for resumption; while the non-
resumption mode might even verify the authentication signatures in
the handshake and not letting server send non-handshake messages
before sending its 2nd flight. Ugh, getting around those would be
pretty nasty.

-Ilari

---

From: Yoav Nir <[email-masked]>
Date: Sat, 7 Oct 2017 21:37:35 +0300

> On 7 Oct 2017, at 17:17, Nick Sullivan <[email-masked]> wrote:
> 
> Yoav,
> 
> "You’ll need it for Chrome to work with Google, Facebook, and most of the 10% of Alexa top million sites that are using Cloudflare.”

What part of “not making any configuration changes until the second week of January” is not clear to you?

Seriously, I’ve had this conversation with administrators.

Because if they go to their bosses, they get asked if they can guarantee that the update will cause no outage. Of course they can’t.

Then they get asked if Edge has the same problem. Let’s assume the answer is yes.

Then they get asked if they can turn off TLS 1.3 in Edge using GPO (or whatever the remote configuration of Microsoft Windows is called these days). In all likelihood, the answer is yes.

Problem sovled, no?

But, they’ll protest, more than half our employees use Chrome.

So tell them not to use Chrome, says the manager.

Because for the manager the decision to update the middlebox is all risk with no rewards.

Yoav

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 8 Oct 2017 11:09:22 +0300

> stone and applied equally to all problems and decisions.

Unfortunately, things are actually more complicated than that.

I suspect that none of the figures "minimal", 1.5% nor 3.4% are
actually accurate, due to "survivorship bias" (survive to be tested).
This is both due to large variance in results, and Google and FB
disagreeing on impact of the record type hack.

I think Attributing the differences to survivorship bias (or other
similar statistical bias) makes much more sense than attributing the
differences to random chance (I presume the sample sizes are large
enough to easily resolve even 0.1% differences) or a testing mistake.

If asked to guess which result is the closest to the true value, I
would guesss Google's (which is also the largest value). But I do
not have any idea even which direction the true value is (often in
studies it is rather easy to guess the direction of the true value,
even if one can not guess the correction magnitude).

The nasty issue in testing is that there are several classes of
connections, with quite widely varying properties:

1) Residential wired
2) Wireless Mobile
3) Enterprise (includes some schools)
4) Satellite (most probably of minimal use).

I would expect that with residential wired, the failure rates are
minimal, whereas with Enterprise, the failure rates would be pretty
substantial. With wireless mobile in the middle. I have no idea how
satellite would stack up.

I suspect the main factor in differences was proportion of enterprise
networks that were tested. Which would imply that the enterprise
failure rate is much higher than 3.4%. And even getting the failure
rate reduced to 1%, the enterprise failure rate would still be
substantially higher than 1%.

And analyzing individual middleboxes to determine the kind of
intolerance is only useful for guiding what kind of modifications to
test on the field, since estimating any useful statistics from
just the devices or software behavior is virtually impossible.

-Ilari

---

From: [email-masked] (Martin Rex)
Date: Mon, 9 Oct 2017 19:00:03 +0200 (CEST)

> - Try to make small adaptations to TLS 1.3 to make it work better with

Return to the proper TLSv1.2 record format with true ContentTypes
(hiding them doesn't add any security anyways).

With the needlessly broken ContentTypes, we will be unable to support
TLSv1.3 in our current apps.

The needless changes break streaming of layered IO and end-of-communication
discovery for long-running requests, because it is not possible to
reliably distinguish a warning-level closure alert from a pipelined
continuation of app data.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Mon, 9 Oct 2017 19:21:01 +0200 (CEST)

> before sending its 2nd flight. Ugh, getting around those would be

Fixing the backwards-incompatibilities in the TLS record layer
would be terribly useful for streaming-optimized IO layers as well,
i.e. ensure the the TLS record properly identifies ContentType,
and that a TLSv1.3 handshake ends with CCS followed by 1 Handshake message.

-Martin

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 9 Oct 2017 21:16:31 +0300

> and that a TLSv1.3 handshake ends with CCS followed by 1 Handshake message.

Unfortunately, doing that would do really bad things to security.

And the middleboxes I am talking about actually parse every cleartext
handshake message. Change anything in any message and they fail. And
fixing some known vulnerabilities in TLS 1.2 is not possible without
changing the structures around.

In fact, I think the record layer changes in TLS 1.3 actually _reduce_
intolerance, not _increase_ it. If your middlebox is not as anal as I
described above, it probably falls into copying data back and forth
when it loses the handshake. However, the changes into ServerHello
could easily cause trouble even with such middleboxes.

Here what might work getting around those really annoying middleboxes
(and this is pretty nasty):

- Add back the session field, echo field from client
- Add dummy zero into place of compression method, so TLS 1.2 parsers
  can parse the message.
- Fix ServerVersion at TLS 1.2, send true version in supported_versions
  extension.
- If the version is TLS 1.3, the session id is non-empty and 0-RTT was
  not accepted, insert fake ChangeCipherSpec message immediately after
  ServerHello and change outer content-type of the next record to 22
  (instead of 23). The client can do the same.

This might be able to make the middlebox think that first part of
the handshake is actually TLS 1.2 stateful session resumption. But as
said, blech at the hack. Hmm... Ciphersuites could cause problems
still.

With less annoying middleboxes, the following would also work:

- Add two zeros into ServerHello so the message can be parsed the same
  way as TLS 1.2.

And with slightly more annoying than that:

- Add two zeros into ServerHello so the message can be parsed the same
  way as TLS 1.2.
- Fix ServerVersion at TLS 1.2, send true version in supported_versions
  extension.

-Ilari

---

From: [email-masked] (Martin Rex)
Date: Tue, 10 Oct 2017 10:52:26 +0200 (CEST)

Ilari Liusvaara <[email-masked]> wrote:
[ Charset UTF-8 unsupported, converting... ]
> Unfortunately, doing that would do really bad things to security.

Nope, none at all.  I'm _not_ asking for protocol changes, just that
the TLS handshake continues to end with CCS + HS, and ContentTypes
remain visible.  Contents of all handshake messages, and whether
and how that content is protected, remains subject to negotiated
protocol version which may vary significantly.

> changing the structures around.

Changing the contents of TLS handshake messages _other_ than
ClientHello+ServerHello is fine with me.  I also don't care which
of the handshake messages are clear vs. encrypted.

What I'm mainly asking for is keeping TLS record ContentType visible
(Handshake, AppData, CCS, Alert), and having a CCS before the final
Handshake record of a TLS handshake.  I'm really looking *ONLY* at
the TLS record layer semantics.

I have an issue with the borked TLS record layer protocol at the *ENDPOINT*,
because TLSv1.3 is never going to work as a drop-in replacement for us with
the current TLS record layer breakage.  This is about
(a) streaming-optimized IO for the handshake phase
(b) CCS to recognize the final step of the handshake phase
(c) and Content-Type visible Alerts to distinguish
End-of-Connection alerts (both fatal error or warning-level
close_notify) from next AppData record -- so that the body
of an AppData record can be left in the network receive buffers
and be visible through "network readable" socket event(s).

Having to redesign the entire application network read event model
in order to juggle around with an unprotected-but-not-yet-processible
AppData record would be a royal PITA, as much as not being able to
recognize premature client-side termination of a longrunning request
(which Web Browser navigation and complex page designs cause all the time).

> could easily cause trouble even with such middleboxes.

I personally hate network middleboxes other than plain NAT, and I'm
violently opposed to MITMs (aka TLS-inspecting network middleboxes).
I will certainly not mind if those latter break.  Broken non-malicious
middleboxes are obnoxious, too, and create a significant & needless
support load.  A lot of our customers use some kind of totally broken
transparent internet proxies, which let TCP connect through, but
silently close the network connection after TLS ClientHello was sent.

Such behaviour is indistinguishable from a choking TLS implementation,
such as Microsoft IIS with SChannel (receiving SSLv3 ClientHello with
ClientHello.client_version=(3,3) or a Win2012+ IIS receiving ClientHello
without the optional TLS extension SNI).

And when telling customers to check their firewall rules, they often
come back saying: "but telnet connects".  Yup, braindead firewall.

> - Add two zeros into ServerHello so the message can be parsed the same

You mean for ServerHello?  Yes, it would be highly preferable to
make ServerHello fully backwards compatible (with respect to the PDU parser)
so that you don't have to change horses midway while parsing ServerHello.

> - Fix ServerVersion at TLS 1.2, send true version in supported_versions

wfm.

>   (instead of 23). The client can do the same.

fake CCS before the final HS of a TLS handshake would make me happy. :)

-Martin

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 10 Oct 2017 11:11:59 +0200

Hi Martin,

> protocol version which may vary significantly.

FWIW: Making the ContentType visible is a protocol change since the
current version of the TLS / DTLS 1.3 protocol encrypts them.

Ciao
Hannes

PS: I think sending fake ChangeCipherSpec messages around is a terrible
idea.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 10 Oct 2017 12:41:47 +0300

> [ Charset UTF-8 unsupported, converting... ]

Lol.

> protocol version which may vary significantly.

Visible content-types cause problems with post-handshake
authentication.

> the TLS record layer semantics.

Well, these annoying middleboxes do care about that.
 
> (which Web Browser navigation and complex page designs cause all the time).

For that, even more annoying than the invisbile content-types is record
padding (actual security improvment). If the content-type was always in
fixed place, one could usually (at least for GCM and POLY1305 modes)
compute the masking value pretty fast, but that does not work because of
padding.

> come back saying: "but telnet connects".  Yup, braindead firewall.

Unfortunately, what breaks is mostly not MITM boxes, since ones that
are not especially badly coded know not to try to forward unknown
extensions (which could, e.g., trigger TLS 1.3).

This is about "non-malicious" middleboxes. I put that in quotes,
because I have real problems trying to come up with any sort of "legit"
reason why these middleboxes try to parse ServerHello (reverse-proxy
middleboxes are different story, but the problematic middleboxes appear
to be forward proxies).

> so that you don't have to change horses midway while parsing ServerHello.

Aargh, The last point is wrong in this context (trying to disguise TLS
1.3 handshake as TLS 1.2 stateful session resumption). The dummy zeros
for compatiblity would form dummy session and compression fields. Of
course you do not want to insert those if you got session and
compression fields already.

The two dummy zeros are needed in less annoying compatiblity hack.

> fake CCS before the final HS of a TLS handshake would make me happy. :)

Well, if there is no client certificate, the final client CCS followed by
encrypted handshake record would be end-of-handshake (since the next message
would be Client Finished, which always ends the handshake in TLS 1.3).
However, if there is client certificate, it would not be, since it would
then tag the first record of client certificate.

(On the server side, the CCS would be between ServerHello and
EncryptedExtensions, and EncryptedExtensions would get tagged as
handshake).

If dealing with this most annoying kind of middlebox, moving when this
fake CCS is inserted is not an option, since trying to move it makes
the middlebox choke.

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 10 Oct 2017 12:42:42 +0300

> PS: I think sending fake ChangeCipherSpec messages around is a terrible

Oh, me too. That was just thinking what it would take to get around
some really annoying middleboxes.

-Ilari

---

From: [email-masked] (Martin Rex)
Date: Tue, 10 Oct 2017 13:15:54 +0200 (CEST)

> current version of the TLS / DTLS 1.3 protocol encrypts them.

I haven't looked at DTLS 1.3, but from what I remember TLS 1.3
has _two_ ContentTypes, one in the clear in the original TLS record
structure, and one encrypted, and the cleartext ContentTypes is
IIRC specified to contain bogus/misleading information.

Since hiding of the ContentType provides ZERO[*] security value,
fixing the cleartext ContentType to carry the true value is not
really a protocol change.

Conceptually, for the TLS *ENDPOINTS*, I prefer a code layering approach
with a transport-free TLS implementation by a huge margin.
Falling up and down huge callstacks with arbitrarily incomplete TLS records
results in huge amounts of complex, poor and inefficent code.

And the IO middleware layer should not have to bother with TLS protocol
versions.

-Martin

 [*] the security value of the hidden ContentType is zero, because
when capturing an entire TLS session, one will be able to
identify the real content types context-free heuristically in 99.5% of
the time looking at all records, and when knowing the server, one
can determine all the content types in 99,9999% of the time.

The hiding of the content type is only sufficiently awkward
to break streaming IO of communication layers above TLS, as well
as efficient connection state management.

---

From: Hubert Kario <[email-masked]>
Date: Tue, 10 Oct 2017 18:37:13 +0200

On Saturday, 7 October 2017 20:37:35 CEST Yoav Nir wrote:
> > 10% of Alexa top million sites that are using Cloudflare.”
> Because if they go to their bosses, they get asked if they can guarantee
> that the update will cause no outage. Of course they can’t.
> 
> Then they get asked if they can turn off TLS 1.3 in Edge using GPO (or
> whatever the remote configuration of Microsoft Windows is called these
> days). In all likelihood, the answer is yes.
> 
> Problem sovled, no?
> 

also the middlebox vendor will say that "we do not support TLS1.3", after you 
spell out that proper TLS1.2 support infers TLS1.3 support...

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic