Add support of TLS 1.3 to Best Practices

[CymruUSA]

After working on my own site trying to not only improve my lighthouse score but to provide a better experience all round, I started to look into my website/pwa security. I had TLS1.2 enabled and had deprecated 1.1, 1.0 and SSL but after a little digging, I realized that I didn't have TLS1.3 support. Given that 1.2 is over 10 years old and 1.3 is now well and truly the future, it would make sense to add it to the Best Practices section of the Lightouse Report.

TY

[patrickhulce]

Thanks for filing @CymruUSA!

This is a great idea and it looks like we already have the protocol support to do it too with Security.CertificateSecurityState. A great candidate for our new trust and safety category perhaps @Beytoven? :)

[patrickhulce]

Seems super useful and in scope for recent safety initiatives.

[connorjclark]

I think we should approach CDT first, see if this should be in issues panel.

[patrickhulce]

see if this should be in issues panel.

Does that mean we should not support it in Lighthouse? If we have everything needed emitted by protocol already I'm not sure I understand the connection of whether it should also be in issues.

[connorjclark]

Unclear :) we're gonna collect a bunch of security-adjacent audit ideas we could do and talk to devtools folks about how to determine what should be in devtools & consumed in LH via issue panel / what should be done in LH

[rik]

I think TLS 1.3 could be listed in the performance section as well given the roundtrips saved compared to previous versions.

[connorjclark]

roundtrips saved

@patrickhulce does this seem like something we can model in Lantern?

[patrickhulce]

@patrickhulce does this seem like something we can model in Lantern?

Yep we could! It's basically what we do with the preconnect audit today. If we had this extra TLS information from the protocol, we could actually improve our lantern estimates because everything is assumed to be configured correctly with TLS false start today

https://github.com/GoogleChrome/lighthouse/blob/fb18dfe70e89d752a46deabe2de8a21b414ceb7e/lighthouse-core/lib/dependency-graph/simulator/tcp-connection.js#L145-L146

[connorjclark]

Some notes on this topic ...

https://almanac.httparchive.org/en/2020/security#protocol-versions

• SSL = deprecated by TLS. They do the same job.
• Useful explainer on TLS False Start. Also explain TCP Fast Open. https://blogs.windows.com/msedgedev/2016/06/15/building-a-faster-and-more-secure-web-with-tcp-fast-open-tls-false-start-and-tls-1-3/
• Another on TLS False Start. https://blog.chromium.org/2011/05/ssl-falsestart-performance-results.html
• Much deeper explainer. https://hpbn.co/transport-layer-security-tls/ / https://sites.google.com/a/google.com/flip/falsestart-in-chrome
• Poking around in Chromium source tells me that False Start "requires ALPN, ECDHE, and an AEAD."
• Some details on the historical pains of getting Fast Start to work https://bugzilla.mozilla.org/show_bug.cgi?id=658222

My initial question when researching this was, how can we detect if False Start works for a server? Does a server need to be configured for it to work, or is it something a browser does? From the links above, I'm pretty sure that a site does not need to do anything beyond using TLS >= 1.2.

My next question is the same, but for TCP Fast Open–and also, how would it look to model that in lantern too... but I have to leave it here for now.

---

Security.CertificateSecurityState has a modernSSL property, which caught my eye. [code] (https://source.chromium.org/chromium/chromium/src/+/master:chrome/browser/devtools/protocol/security_handler.cc;l=132;drc=073e74ade285c0c22ef01bccdf260854d7b1aa85) false if TLS < 1.2, or for various other reasons not important to our discussion here.