On Mon, Dec 18, 2017 at 11:35 AM, David Benjamin <david...@chromium.org> wrote:
> > > 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 ≥ 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. > I think this would be fine, but not imperative. -Ekr > > 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 “Firepower” 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’s HTTPS scanning feature breaks > 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-chrome-63-using-the-js-sdk/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
