Why do workers.dev subdomains *still* use TLSv1 & 1.1?

It’s as the title states. The “???” emphasis is to underscore the fact that each protocol is not only weak but depreciated. In fact, according to DigiCert (among most Cert vendors), which issues CloudFlare’s root certificate :

I want to call a vote to disable their use on our workers.dev subdomains.

1 Like

Not sure if @intr0’s question is specifically this, but the question would be better rephrased as “why do they still support TLSv1.0 and TLSv1.1?”.

Also, they don’t auto-redirect to HTTPS (there is the .dev preload, but not all browsers and devices use that list, unfortunately).


Oh I see, I’ll ask around internally. :+1:


That merely shows what version your UA is capable of handling / the highest version. It doesn’t reveal all versions in use.

(Attachment publicKey - [email protected] - dc622ac9.asc is missing)


Indeed. still is a better phrasing. Much appreciated. And yeah, despite Google’s relatively recent spate of TLDs that were to be forward thinking security-wise by being hard-coded into Google’s (exactly…) preload list from which Mozilla, Microsoft, & Apple derive their lists for their respective browsers… it’s not reality for many people.

Peace and Health!

(Attachment publicKey - [email protected] - dc622ac9.asc is missing)

@mdemoura ,

The one disadvantage of replying by email is, e.g., me not seeing your last (this) reply to @matteo. Apologies if my initial response to your first was off-base. It sounds to me as such now that I came to this post.

EDIT: So, this is interesting. After just answering a question regarding Google AMP, I ran a scan on amp.dev using Qualys. Here’s the results:


Apparently Google has TLS1.0 and 1.1 hardcoded into the .dev TLD along with Strict-Transport-Security. :joy::joy::joy: What good is being preloaded if you’re vulnerable to BEAST attacks? They need new blood in that “tech” company…


~ Ⓐ intr0
Sent using ProtonMail Enterprise

(Attachment publicKey - [email protected] - dc622ac9.asc is missing)

The issue is mostly for non-browser requests. Browsers usually support HSTS.

Browsers, too, though, are impacted. HSTS cannot protect against / act as a barrier / the UA connecting via TLSv1.0. HSTS doesn’t force the UA to use TLSv1.2 or 1.3 - it merely instructs the UA to use HTTPS by default, irregardless of which version TLS is used.

However, this issue for the .dev zone ultimately lies at Google’s end bc any domain registered using .dev, and I presume any of their other HSTS by default zones, are issued certs supporting TLSv1.0.

1 Like