Dear all, The upcoming release of Google Chrome 70 is expected to enable the final version of TLS 1.3. As the release has progressed through our early release channels, we have learned about some deployment issues we would like to share with the community.
First, we are aware of some intolerance to the final TLS 1.3 code point, 0x0304. Prerelease versions of OpenSSL 1.1.1, namely -pre6 and earlier, implemented the draft versions of TLS 1.3 incorrectly <https://github.com/openssl/openssl/issues/7315>. Although the draft versions used separate 0x7fxx code points for forward-compatibility, OpenSSL incorrectly also interpreted 0x0304 as a draft version. These servers will respond to a TLS 1.3 ClientHello with a draft version, rather than TLS 1.2, and fail to interoperate. Early adopters of OpenSSL should upgrade to the final 1.1.1 release. Those that cannot upgrade quickly should disable the draft TLS 1.3 in configuration. We do not believe this problem to be widespread and do not intend to delay TLS 1.3 in Chrome for it. Second, TLS 1.3 includes a downgrade signal <https://tools.ietf.org/html/rfc8446#section-4.1.3> in the ServerHello random field that could not be deployed in draft versions. This signal strengthens <https://crypto.iacr.org/2018/affevents/cwtls/medias/Karthik_Bhargavan.pdf> TLS 1.3 connections while remaining fully backwards compatible with TLS 1.2 and earlier. Unfortunately, despite the solid compatibility story, we are observing deployment issues. We believe these are caused by non-compliant TLS-terminating proxies which, rather than generating their own random values, copy the value from the origin server. This behavior is incorrect for all <https://tools.ietf.org/html/rfc5246#section-7.4.1.3> prior <https://tools.ietf.org/html/rfc4346#section-7.4.1.3> versions <https://tools.ietf.org/html/rfc2246#section-7.4.1.3> of TLS. When such a proxy terminates a connection between a TLS 1.3 client and server, the resulting pair of TLS 1.2 connections appear as a downgrade and are rejected. We are aware of two vendors whose products have this bug: Cisco and Palo Alto Networks, although there may be more. We reported the issue to Cisco in December 2017. They released the fix this past August and have published an advisory <https://www.cisco.com/c/dam/en/us/td/docs/security/firepower/SA/SW_Advisory_CSCvj93913.pdf>. Palo Alto Networks recently discovered the issue on their devices and are planning to release PAN-OS 8.1.4, PAN-OS 8.0.14, and PAN-OS 7.1.21 to fix this, tentatively by Nov 30th. As random values in security protocols are there for a reason and assumed to be random by all security analysis, we would advise that all affected vendors treat such flaws as security issues, and not mere functional flaws. Additionally, vendors should note the Protocol Invariants <https://tools.ietf.org/html/rfc8446#section-9.3> section of RFC 8446, which points out areas historically dense in errors. Due to the above, we will sadly be shipping TLS 1.3 in Chrome 70 with the server-random check temporarily disabled. While we still have downgrade protection via the Finished check, we consider this additional protection an important part of TLS 1.3 and plan on re-enabling it in the near future. Additionally, we are disabling the False Start <https://tools.ietf.org/html/rfc7918> optimization on connections with the downgrade signal, as False Start skips the Finished check. Note this effectively disables the optimization on affected middleboxes. Vendors should fix the underlying ServerHello random flaw to recover performance. We would recommend other clients considering similar measures to also disable False Start when the signal is present. To that end, we ask that TLS 1.3 server deployments leave the signal enabled on the server. The False-Start-only enforcement is valuable, and the server signal aids client measurement. Compatibility issues can be mitigated instead on the client. David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
