I ran into a surprising failure while trying to access archive.today on an Xfinity connection with Advanced Security / SafeBrowse enabled.

At first glance, it looked like a TLS problem:

$ curl https://archive.today

curl: (35) TLS connect error: error:0A00010B:SSL routines::wrong version number

The interesting part is that DNS was not the issue. The hostname resolved normally through encrypted DNS:

$ resolvectl flush-caches
$ resolvectl query archive.today

archive.today: 104.36.80.106                   -- link: wlp2s0

-- Information acquired via protocol DNS in 164.3ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: yes
-- Data from: network

The important line:

Data was acquired via local or encrypted transport: yes

So this was not classic DNS interception. The DNS lookup succeeded, and the result came back over encrypted transport.

The failure happened later, during the TLS connection.

Testing TLS with and without SNI

TLS clients normally send the hostname they want in the ClientHello using SNI, or Server Name Indication. This is needed because many sites share the same IP address, and the server needs to know which certificate to present.

I tested the connection with SNI set to archive.today:

$ openssl s_client -connect archive.today:443 -servername archive.today -brief </dev/null

Connecting to 104.36.80.106
0061116DC0770000:error:0A00010B:SSL routines:tls_validate_record_header:wrong version number:ssl/record/methods/tlsany_meth.c:77:
0061116DC0770000:error:0A000197:SSL routines:SSL_shutdown:shutdown while in init:ssl/ssl_lib.c:2804:

Then I tested the same IP and port without SNI:

$ openssl s_client -connect 104.36.80.106:443 -noservername -brief </dev/null

Connecting to 104.36.80.106
depth=0 CN=104.36.80.106
verify error:num=18:self-signed certificate
CONNECTION ESTABLISHED
Protocol version: TLSv1.2
Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
Peer certificate: CN=104.36.80.106
Hash used: SHA256
Signature type: rsa_pss_rsae_sha256
Verification error: self-signed certificate
Peer Temp Key: X25519, 253 bits
DONE

That is the key difference:

With SNI = archive.today: TLS fails
Without SNI: TLS connects

The IP was reachable. Port 443 was reachable. TLS itself was possible.

The failure only happened when the ClientHello included the hostname archive.today.

That strongly suggests that the network was filtering based on SNI.

What this means

This is not evidence that Xfinity was decrypting HTTPS traffic. There is no sign here that the contents of the HTTPS session were visible.

But it does suggest that Xfinity Advanced Security was inspecting plaintext TLS metadata. In particular, it appears to be using the SNI value from the TLS ClientHello to decide whether to block or interfere with the connection.

A simplified flow looks like this:

1. Client resolves archive.today using encrypted DNS
2. DNS returns 104.36.80.106
3. Client connects to 104.36.80.106:443
4. Client sends TLS ClientHello with SNI = archive.today
5. Network device sees the SNI
6. Connection is blocked, reset, or replaced with non-TLS data
7. curl/OpenSSL reports "wrong version number"

The wrong version number error is consistent with receiving something that is not a valid TLS record during the TLS handshake. It does not necessarily mean the server has an old or incompatible TLS configuration.

Why encrypted DNS did not prevent this

Encrypted DNS hides the DNS query from the local network. It does not automatically hide the hostname used during the TLS handshake.

Without ECH, the SNI field is still visible in the TLS ClientHello.

So the privacy properties are different:

Encrypted DNS:
  hides the DNS lookup

TLS without ECH:
  encrypts the HTTP contents
  but may expose the hostname in SNI

ECH:
  encrypts the ClientHello hostname
  if the client and server both support it

VPN/Tor:
  hides the destination connection from the local ISP

In this case, encrypted DNS was working, but the TLS ClientHello still exposed the hostname.

Checking whether ECH is available

Encrypted Client Hello (ECH), is the modern replacement for the older ESNI design. ECH can hide the real hostname in the TLS ClientHello, but the site has to publish ECH configuration through DNS, usually using an HTTPS or SVCB record.

For archive.today, there was no HTTPS record:

$ dig HTTPS archive.today @1.1.1.1

; <<>> DiG 9.20.18-1ubuntu2.1-Ubuntu <<>> HTTPS archive.today @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15443
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;archive.today.                  IN      HTTPS

;; AUTHORITY SECTION:
archive.today.           85647   IN      SOA     mick.archive.li. admin.archive.today. 2036183339 1200 300 604800 3600

The important part:

ANSWER: 0

systemd-resolved reported the same thing:

$ resolvectl query -t HTTPS archive.today

archive.today: resolve call failed: Name 'archive.today' does not have any RR of the requested type

So archive.today was not advertising ECH. The client had no ECH configuration to use.

For comparison, shangen.org does publish an HTTPS record with ECH:

$ resolvectl query -t HTTPS shangen.org

shangen.org IN HTTPS 1 . alpn="h3,h2" ipv4hint=104.21.88.161,172.67.185.204 ech="\000E\254\013\000A\211\000\032\000\032\149\227J_]\180\1866#h\212\227\228x\145\0115~\137G\142\223\255\009\158\178j\222\025\029`\028\000\004\000\001\000\001\000\018cloudflare-ech.com\000\000" ipv6hint=2606:4700:3036::6815:58a1,2606:4700:3037::ac43:b9cc -- link: wlp2s0

-- Information acquired via protocol DNS in 108.2ms.
-- Data is authenticated: yes; Data was acquired via local or encrypted transport: yes
-- Data from: network

The relevant field is:

ech="..."

That means an ECH-capable client can use this DNS record to encrypt the real ClientHello. With Cloudflare ECH, the visible outer name may be something like:

cloudflare-ech.com

while the real hostname is carried inside the encrypted ClientHello.

Practical conclusion

The evidence points to SNI-based blocking by Xfinity Advanced Security:

  • DNS resolution over encrypted transport: works
  • archive.today resolves to 104.36.80.106
  • TLS to 104.36.80.106 without SNI: works
  • TLS to archive.today with SNI: fails
  • archive.today does not advertise ECH

This does not show HTTPS decryption. It does show that encrypted DNS alone is not enough to hide the target hostname from the access network.

For this specific site, the practical options are:

  • Disable Xfinity Advanced Security / SafeBrowse
  • Use a VPN
  • Use Tor
  • Use a different network
  • Wait for the site to support ECH

A VPN or Tor hides the destination connection from the local ISP; ECH would hide the hostname in the TLS handshake instead.

The broader lesson is simple: encrypted DNS protects the DNS query, but unless ECH is available and actually used by the client, the hostname can still leak through TLS SNI.