Why google.com still serves TLS 1.0 in 2026 (and why your scanner should flag it)

We had a moment of disbelief in the office today. We pointed UnveilScan at google.fr for a Basic scan and watched the score settle at 63 / D. The TLS subscore alone was 40. Surely a bug — Google practically invented modern TLS. SSL Labs has handed them an A+ since the dawn of time.

It is not a bug. google.fr still negotiates TLS 1.0 and TLS 1.1 in April 2026. So does google.com. So does cloudflare.com. The frontends accept the handshake, complete a real key exchange, and serve content. We checked twice with two different stacks. The finding is correct.

The two-line proof

You don't need a scanner. From any shell with a recent Go installed:

cat <<'EOF' > /tmp/probe.go
package main
import (
    "crypto/tls"
    "fmt"
)
func main() {
    for _, h := range []string{"google.com", "cloudflare.com", "github.com"} {
        cfg := &tls.Config{ServerName: h, MinVersion: tls.VersionTLS10, MaxVersion: tls.VersionTLS10}
        c, err := tls.Dial("tcp", h+":443", cfg)
        if err != nil {
            fmt.Printf("%-20s rejected: %v\n", h, err)
            continue
        }
        st := c.ConnectionState()
        fmt.Printf("%-20s NEGOTIATED %x %s\n", h, st.Version, tls.CipherSuiteName(st.CipherSuite))
        c.Close()
    }
}
EOF
go run /tmp/probe.go

What we got:

google.com           NEGOTIATED 301 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
cloudflare.com       NEGOTIATED 301 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
github.com           rejected: remote error: tls: protocol version not supported

0x0301 is TLS 1.0. The cipher is real (ECDHE with CBC-SHA1) — not a server politely truncating the handshake before key exchange, but a complete, bidirectional TLS 1.0 connection that can carry application data. github.com shows what a strict configuration looks like: a clean rejection at the supported_versions extension level.

Why is this still happening?

Big CDNs make a deliberate trade-off. The world has long-tail clients that never get updated: industrial PLCs from 2009, set-top boxes, embedded SDKs that vendored OpenSSL 1.0.0, payment terminals stuck on JDK 7. Killing TLS 1.0 means breaking those clients. From a Cloudflare or Google product manager's perspective, "0.001% of legitimate traffic broken" is a much louder signal than "Mozilla flags us in their docs". Compatibility wins.

This is also why the migration timelines stay loose. PCI-DSS gave its hard deadline in 2018. Browser vendors removed UI support in 2020. RFC 8996 declared TLS 1.0/1.1 formally obsolete in 2021. And five years later, the world's two largest edges still answer in TLS 1.0. The IETF can declare anything; deprecation is a sociological event, not an engineering one.

Why we flag it as CRITICAL anyway

TLS 1.0 has known cryptographic weaknesses (BEAST, weak SHA-1 PRF, CBC mode IV reuse) that are rarely exploited end-to-end against modern servers but compound with anything else broken in the chain. More importantly, our job is to grade against the standards that actually govern liability:

• PCI-DSS 4.0 § 4.2.1 — Strong cryptography only; explicitly bars TLS 1.0/1.1 for any cardholder-data-touching channel.
• ANSSI Reco-TLS R1 — TLS 1.2 minimum, TLS 1.3 recommended, no exception.
• RFC 8996 (BCP) — "TLS 1.0 and TLS 1.1 MUST NOT be used".

A scanner that lets these slide for "compatibility" is grading against industry average, not against compliance. We don't think that helps the user who runs a scan to know whether their next audit will pass.

How to fix it on your own infrastructure

nginx

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers ECDHE+AESGCM:ECDHE+CHACHA20:!aNULL:!MD5;

Apache (httpd 2.4+)

SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLHonorCipherOrder off
SSLCipherSuite HIGH:!aNULL:!MD5:!3DES

Caddy

example.com {
    tls {
        protocols tls1.2 tls1.3
    }
}

Verify with the Go probe above (or openssl s_client -tls1 -connect your-domain.com:443 — a clean reject is the goal). Re-run UnveilScan and the CRITICAL finding clears within a Basic scan (~1 minute).

Should Google fix this?

Probably yes. The compatibility excuse was already weak in 2021. Every modern client has TLS 1.2 or 1.3 by now; the embedded long tail that genuinely cannot speak TLS 1.2 is small enough that the fallout from killing the legacy listener would be less than what Google causes any random Wednesday with a Search ranking change. But that decision is a Google product call, and we are not Google.

What we control is what we report. So google.fr sits at 63/D until that listener is turned off, the same as your domain would.