Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues

From: Loganaden Velvindron <[email-masked]>
Date: Mon, 6 Nov 2017 18:31:32 +0400

On Sat, Oct 7, 2017 at 12:16 AM, Eric Rescorla <[email-masked]> wrote:
> 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.
>

We (hackers.mu) ran tests across different Mobile & FTTH providers,
and large wifi hotspot vendors across the island of Mauritius:

Mauritius Telecom FTTH: no issues with TLS 1.3
Emtel (mobile): no issues with TLS 1.3
Mauritius Telecom (mobile): no issues with TLS 1.3
AlwaysOn: Gateway has issues with TLS 1.3 (draft-18), when forcing all
HTTPS traffic to their HTTPS web-based portal.

Before authentication via SSL/TLS:

./bin/openssl s_client -connect tls13.crypto.mozilla.org:443 -tls1_3
-CApath=/etc/ssl/certs/
CONNECTED(00000003)
140130750743872:error:14094410:SSL routines:ssl3_read_bytes:sslv3
alert handshake failure:ssl/record/rec_layer_s3.c:1471:SSL alert
number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 184 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
SSL-Session:
Protocol : TLSv1.3
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1509976305
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---

I'm reaching out to the AlwaysOn service, which appears to be quite
well popular in South Africa as well.

//Logan
C-x-C-c

---

From: Matt Caswell <[email-masked]>
Date: Mon, 6 Nov 2017 14:37:53 +0000

> ./bin/openssl s_client -connect tls13.crypto.mozilla.org:443 -tls1_3

Note that the "-tls1_3" option to s_client forces *only* TLSv1.3 to be
negotiated. Therefore, if the web based portal doesn't also support
TLSv1.3 then this will fail.

Matt

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