From 48fdba71ccec0720bcce0a33ab2081a78cd96e47 Mon Sep 17 00:00:00 2001 From: Joost de Valk Date: Fri, 17 Jul 2026 08:16:44 +0200 Subject: [PATCH] =?UTF-8?q?fix(security):=20RFC=208446=20is=20obsolete=20?= =?UTF-8?q?=E2=80=94=20cite=20RFC=209846=20for=20TLS=201.3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit RFC 9846 (July 2026) obsoletes RFC 8446. https-tls.md led with 8446 as its primary source and asserted "TLS 1.3 (RFC 8446) is the current version" in the body, so both the citation and the claim were stale. 9846 is a minor revision: same version number, backward compatible. Nothing about the page's advice changes and the status stays `required`. Also add the nuance that "TLS 1.2 remains acceptable" no longer means "TLS 1.2 is fine forever". RFC 9851 (July 2026) puts TLS 1.2 in feature freeze — urgent security fixes only — and post-quantum key exchange is TLS 1.3-and-later only. The page said TLS 1.2 was acceptable and left a reader to conclude it was equivalent; it isn't, and the gap grows. Deliberately NOT changed: TLS 1.2 stays acceptable for websites. RFC 9852 (BCP 195) mandates TLS 1.3 for *new protocols*, which is not a statement about site configuration, so it would be an overreach to cite it as pressure on operators. The Mozilla Intermediate profile remains the right default. Co-Authored-By: Claude Opus 4.8 (1M context) --- src/content/spec/security/https-tls.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/src/content/spec/security/https-tls.md b/src/content/spec/security/https-tls.md index e58505b4..9a910209 100644 --- a/src/content/spec/security/https-tls.md +++ b/src/content/spec/security/https-tls.md @@ -7,10 +7,13 @@ status: required order: 10 appliesTo: [all] relatedSlugs: [hsts, caa-records, content-security-policy, mixed-content] -updated: "2026-07-09T00:00:00.000Z" +updated: "2026-07-17T00:00:00.000Z" sources: - - title: "RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3" - url: "https://www.rfc-editor.org/rfc/rfc8446" + - title: "RFC 9846 — The Transport Layer Security (TLS) Protocol Version 1.3" + url: "https://www.rfc-editor.org/rfc/rfc9846" + publisher: "IETF" + - title: "RFC 9851 — TLS 1.2 is in Feature Freeze" + url: "https://www.rfc-editor.org/rfc/rfc9851" publisher: "IETF" - title: "Mozilla SSL Configuration Generator" url: "https://ssl-config.mozilla.org/" @@ -25,7 +28,9 @@ sources: ## What it is -HTTPS is HTTP carried over TLS, a protocol that encrypts and authenticates the connection between the browser and the server. TLS 1.3 (RFC 8446) is the current version; TLS 1.2 remains acceptable. Everything earlier — TLS 1.0, TLS 1.1, and all versions of SSL — is broken and must be disabled. +HTTPS is HTTP carried over TLS, a protocol that encrypts and authenticates the connection between the browser and the server. TLS 1.3 is the current version, specified by RFC 9846 — a July 2026 revision that obsoleted RFC 8446 without changing the version number or breaking compatibility. TLS 1.2 remains acceptable. Everything earlier — TLS 1.0, TLS 1.1, and all versions of SSL — is broken and must be disabled. + +"Acceptable" is not the same as "equal", though, and the gap is widening rather than holding steady. TLS 1.2 is in feature freeze (RFC 9851): it receives urgent security fixes and nothing else, and post-quantum key exchange is being specified for TLS 1.3 and later only. Keeping TLS 1.2 enabled for the clients that still need it is sound; treating it as a version you can sit on indefinitely is not. What HTTPS does not do is vouch for the site. The certificate proves you are talking to the genuine holder of the name in the address bar, and that nobody on the path can read or alter the bytes. It says nothing about whether that party is honest: a phishing page served over flawless HTTPS shows the same padlock a bank does. HTTPS secures the channel, not the character of whatever is at the far end of it.