MIME-Version: 1.0
Sender: davidben@google.com
From: David Benjamin <davidben@chromium.org>
Date: Mon, 18 Dec 2017 14:35:12 -0500
Message-ID: <CAF8qwaA4su2j-Lh9XRcLbT_Tysg9H24ys=TCC=Rd1bvrFNds7A@mail.gmail.com>
To: tls@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/i9blmvG2BEPf1s1OJkenHknRw9c>
Subject: [TLS] Additional TLS 1.3 results from Chrome
Precedence: list

Dear all,

The recent release of Google Chrome 63 enabled (effectively) TLS 1.3
draft 22 for 95% of stable channel users who updated. (Our previous
results were on our beta channel.) While, in the past, we have
demurred[1] from providing details about problematic products we now
plan to alter that stance. It is late in the game for TLS 1.3 and we
have likely exhausted the scope of wire-format tricks to improve
deployment viability (although there is one more helpful tweak below).
Since other vendors will also be seriously deploying TLS 1.3 soon, we
want to share all that we have learned from Chrome.

We note, however, that even being included in a stable release of
Google Chrome doesn=E2=80=99t provide a full picture of any issues. For
example, enterprise customers may choose not to release any new
versions of software into their organisations in the run-up to
Christmas and New Year=E2=80=99s. Also, we are aware that only a tiny fract=
ion
of issues result in user reports.

This experiment in Chrome 63 will end on 2017-12-19, hopefully
ensuring a quiet Christmas.

BSAFE

The web interface on some Canon printers breaks with 1.3-capable
ClientHello messages. We have purchased one and confirmed this with a
PIXMA MX492. User reports suggest that it also affects PIXMA MG3650
and MX495 models. It potentially affects a wide range of Canon
printers.

These printers use the RSA BSAFE library to implement TLS and this
library implements the extended_random extension and assigns it number
40. This collides with the key_share extension and causes 1.3-capable
handshakes to fail.

We understand that this has been fixed in BSAFE =E2=89=A5 4.1, but older
versions still exist in the world. Canon is aware of this and is
planning on issuing firmware updates, although the uptake of firmware
for printers is typically poor.

However, since extension numbers are essentially infinite, this WG may
consider renumbering key_share to avoid the issue.

Dymo (the label-printer manufacturer) is experiencing a similar[2]
issue with some of their software. We have not been able to reproduce
but one guess is that they are also using BSAFE.

(Lastly, we note that in the paper "On the Practical Exploitability of
Dual EC in TLS Implementations", the authors remarked that they had no
evidence that a version of BSAFE with extended_random support ever
shipped. TLS 1.3 appears to have tripped over it.)

Cisco Firepower

After receiving a report of issues with a Cisco =E2=80=9CFirepower=E2=80=9D=
 device we
purchased one to try and reproduce the issue.

We found that Firepower middleboxes in "Decrypt - Resign" mode
terminate TLS connections, but do not send a compliant ClientHello:
They modify the original ClientHello to remove unknown ciphersuites,
EMS, and NPN, but incorrectly forward most other fields from the
original ClientHello, including unknown extensions (supported_versions
and key_shares), and the client random. This breaks TLS 1.3 servers.
Additionally, these devices forward the server random rather than
generating their own (which will break when deploying the TLS 1.3
anti-downgrade feature), and forward unknown signature algorithms
(which will break when deploying, e.g., Ed25519).

Disabling "Decrypt - Resign" mode appears to work around this issue.
To fix this mode, these devices will need to stop forwarding unknown
extensions and generate their own random values.

We have provided Cisco with this information.

Avast Antivirus

We have received one report that Avast=E2=80=99s HTTPS scanning feature bre=
aks
connections that negotiate TLS 1.3. The user reported that disabling
HTTPS scanning solved the issue. We were not able to reproduce so this
might only occur with older versions of Avast.

[1] https://www.ietf.org/mail-archive/web/tls/current/msg24535.html
[2] http://developers.dymo.com/2017/12/12/err_ssl_version_interference-in-c=
hrome-63-using-the-js-sdk/