Should we disable TLS 1.0/1.1?

[mgol]

jquery.com gets flagged by checkers like SSL Labs because of its support for TLS 1.0/1.1. Should we disable it?

I realize impact is limited as modern browsers don't support these TLS versions, so downgrade attacks won't apply there, but still, it'd be good to see which environments we'd break if we disabled old TLS and whether we consider worth it.

[mgol]

We should consider CDN & the rest of the sites separately if possible, IMO. We may want to support more on the CDN than we do on other sites.

[timmywil]

Dropping them means dropping support for certain browsers and devices. See #77

[timmywil]

By the way, let's encrypt is used for all but that cert.

[mgol]

@timmywil I don’t see anything about TLS 1.0/1.1 in that issue. Also, this affects Let’s Encrypt certs as well since they cover e.g. jquery.com which I mention here.

[timmywil]

Not the issue itself. Timo’s comments give more details. It does have to do with TLS 1.0/1.1. All of the testing he did is related to the cdn cert (*.jquery.com & jquery.com), but the letsencrypt certs we have do seem to have the same B score. We could at least update those.

[Krinkle]

We already don't support TLS 1.0 and 1.1 on code.jquery.com. I think this changed between 2018 and 2020, when we were still on Highwinds. It just changed one day. I suspect the reason the impact wasn't noticed, is that we never enforced HTTPS here, so older websites most likely use HTTP, and that continues to work fine in those browsers, even today.

If we assume that the audience of jquery.com, api.jquery.com and blog.jquery.com is more developer-oriented, and not in the critical path of other people's websites, enterprise/legacy situations, or other extended-support scenarios; then it might be fine to turn off, assuming we don't need a wider level of support here than the jQuery CDN.

On the other hand, there's two things to note.

1. We enforce HTTPS on doc sites.

Because we've enforced HTTPS on these domains for a very long time, people using older browsers don't have an obvious alternative way to reach us.

2. What are these older browsers?

Based on:
#77 (comment)
and https://en.wikipedia.org/wiki/Version_history_for_TLS/SSL_support_in_web_browsers

• Chrome: code.jquery.com is reachable on Chrome 49 (2016), which is the last Chrome for WinXP. Chrome 30+ supports TLS 1.2.
• Firefox: code.jquery.com is reachable on Firefox 52 ESR (2017), which is the last for WinXP. Firefox 27+ supports TLS 1.2.
• Internet Explorer: code.jquery.com is reachable on IE9 and IE10 on Win7+ today (we don't support IE8/WinXP). It appears these are TLS 1.0 and 1.1 only by default, but TLS 1.2 was added later. IE11 is available for Win7, and that does support TLS 1.2.
• Safari: code.jquery.com is reachable on Safari 7+ on macOS 10.9+. Safari 7+ supports TLS 1.2.
• iOS: code.jquery.com is reachable on iOS 6+. iOS 5+ supports TLS 1.2.
• Android: code.jquery.com is reachable on Android 4.4+. Android 4.4 supports TLS 1.2.

So in terms of TLS support, TLS 1.0 or 1.1 would in theory benefit:

• WinXP with Chrome < 30, despite an available update.
• WinXP with Firefox < 27, despite an available update.
• WinXP with IE8.
• iOS <= 4, Android <= 4.3, macOS <= 10.8.

However, it's not just about TLS versions. It's also about cipher suites. Now, I was about to say that Cloudflare uses Let's Encrypt, and that means relatively new cipher suites, and thus these browsers can't connect anyway.

But..., while that might be true on a free Cloudflare plan, it's different for the "Enterprise" plan we're on. Cloudflare manages 4 different wildcard certificates for us:

Universal Certificate for jquery.com, *.jquery.com
The certificates in the pack listed below are managed and auto-renewed by Cloudflare.

• (Active) *.jquery.com, jquery.com - SHA256 RSA - Google Trust Services (Managed by Cloudflare)
• (Active) *.jquery.com, jquery.com - ECDSA SHA256 - Google Trust Services (Managed by Cloudflare)

Backup Certificate for jquery.com, *.jquery.com

This Backup certificate has not been deployed. It will be deployed automatically by Cloudflare in the event of a certificate revocation or key compromise. Learn more.

The certificates in the pack listed below are managed and auto-renewed by Cloudflare.

• (Backup)*.jquery.com, jquery.com - SHA256 RSA - Sectigo (Managed by Cloudflare)
• (Backup)*.jquery.com, jquery.com - ECDSA SHA256 - Sectigo (Managed by Cloudflare)

Cloudflare automatically provisions SSL (TLS) certificates for websites on all plans making HTTPS easy and automatic. Provisioned certificates on paid plans are compatible with older browsers.

---

I believe the way it works is that Cloudflare use connection sniffing (a bit like user-agent sniffing) during the TLS handshake to detect older browsers, and offer the more compatible RSA certificate to older browsers, while serving the ECDSA certificate to newer browsers.

Combined with TLS 1.0 and 1.1, this means the older browsers listed above, can indeed all connect to https://jquery.com today, while they cannot connect to code.jquery.com over HTTPS.

For example, Firefox 26 on WinXP:

Even on Windows XP the same browsers offer free updates that support TLS 1.2, for the same OS version and the same hardware. The exception is IE8, which can connect to https://jquery.com today (although the layout is fairly broken, because our stylesheet doesn't support IE8 anymore), but there are no updates for IE on WinXP that enable TLS 1.2 (as far as I know). But... people who used IE8 on WinXP have presumably encountered a broken web for so long now, that they have long switched to Firefox, or Chrome; or switched to Linux; or upgraded to newer hardware with Windows 7.

So... is this important to us?