Carr Digital

Analysis · October 28, 2026

Two clocks on the same internet

I read the certificate on 1,914 exposed RDP hosts. Two run post-quantum key exchange, six hundred sign with SHA-1, and half of them share a private key.

Danny B. Carr, Jr.

On October 28, 2026, I pulled a Shodan export of 1,914 internet-facing hosts that answer TLS on their Remote Desktop port and read every certificate and handshake in it. Two of them had switched on post-quantum key exchange, built to survive a quantum computer that will not exist for years. About six hundred were still signing their certificates with SHA-1 or MD5, hash functions that collided in 2017 and 2008. And just under half of them were serving a certificate that belongs to somebody else too, the same private key copied across dozens of unrelated machines.

That is the whole internet in one file. One set of operators is defending against 2035. Another set never left 2008. Most of them are not doing PKI at all, and a lot of them do not even own their own key.

What the sample is, and is not

This is not the internet. It is a Shodan crawl, dated September 28 to October 28, 2026, of hosts with an exposed Remote Desktop service, 1,774 on port 3389 and the rest on a scatter of alternates, 1,908 distinct addresses in all. RDP skews the population toward Windows and toward boxes somebody stood up and forgot, so read every number below as “the exposed-RDP internet,” not “the web.” The point survives the caveat. If anything this is where the gap should be smallest, because it is all one vendor’s stack.

Every host in the set presents a TLS certificate, because RDP wraps itself in TLS. So an RDP scan is also a certificate survey, 1,914 certs deep, and the certificates are where the real story turned out to be.

Two hosts ready for 2035

Two of the 1,914 offered a hybrid post-quantum key exchange. One was a German municipal gateway offering X25519MLKEM768, the mainstream hybrid that pairs the classical X25519 curve with ML-KEM-768 from FIPS 203. The other was a US university box offering three hybrids at once: X25519, NIST P-256, and NIST P-384, each paired with ML-KEM. One operator turned on the default. The other lit the whole board, up to the P-384 and ML-KEM-1024 tier that targets the highest security level.

Shodan records a post-quantum group only when its probe captures one, so treat two as a floor, not a census. It does not matter. Two, or five, or twenty, the finding is the same: post-quantum key exchange on exposed RDP in late 2026 rounds to zero.

That is not the state of the whole internet, and the gap is the interesting part. On the managed web, post-quantum key exchange is already ordinary. Cloudflare’s Radar put client support above 60 percent in February 2026, up from under 3 percent two years earlier, because Chrome and the large content networks switched on X25519MLKEM768 at both ends by default. The migration is real and it is fast, where someone owns both ends of a connection and flips one switch for millions of users. Exposed RDP is the other place, the long tail where every box is its own decision and nobody made it.

Here is the part worth slowing down for. Both post-quantum hosts still sign their certificates with classical cryptography. Stralsund’s is RSA with SHA-256. UConn’s is ECDSA with SHA-256. Neither has a post-quantum signature, because nobody ships one yet.

That is not a mistake. It is the correct order of operations. A TLS handshake does two separate jobs. The key exchange agrees on a session key, and a signature proves the server’s identity. Only the first one has a deadline today. An attacker can record your encrypted traffic now and decrypt it in fifteen years once a quantum computer exists, so the session key has to be quantum-safe now. That is harvest-now-decrypt-later, and it is the only part of TLS the quantum threat touches early. A signature only has to hold for the length of the handshake. Forging it in 2035 buys an attacker nothing, because the connection is long over and you cannot impersonate a conversation that already happened. So key exchange migrates first, signatures wait. Those two hosts are a textbook picture of the triage: quantum-safe where the clock is running, classical where it is not.

Now turn around and look at the other 1,912.

Six hundred stuck in 2008

Of the 1,914 certificates, 611 are signed with SHA-1 or MD5. SHA-1 has been collision-broken in public since the SHAttered paper in 2017, and the first chosen-prefix collision landed in 2020. MD5 fell in 2004 and was used to forge a real, browser-trusted CA certificate in 2008. Signing a certificate with either is signing it with a pen anyone can copy.

Before that number goes anywhere, the obvious question: who signed them? If a publicly trusted certificate authority issued SHA-1 certs in 2026, that is a scandal. It did not. Zero publicly trusted CAs in this sample issued a weak-hash certificate. The nine non-self-signed exceptions trace to internal or device-vendor CAs, two Active Directory servers and seven embedded-device certs out of Taiwan, not the public web.

The real answer is quieter. 1,834 of the 1,914 certificates, 96 percent, are self-signed. Not issued, not validated, not rotated, just generated once by the machine and never touched. The broken-hash certs are almost all in that pile, and they pool on the oldest boxes. Of the 602 weak-hash self-signed certs, 563 sit on a version of Windows that Microsoft no longer supports: Server 2008 R2, Windows 7, Server 2012 R2. End-of-life boxes run broken hashes at 61 percent. Current boxes run them at 4 percent. Roughly fourteen to one.

Windows generates that self-signed RDP certificate on its own, with no admin involved, and in this sample the hash tracks the age of the box: SHA-1 on the end-of-life releases, SHA-256 on the current ones. The hash is a fossil of the install date, not a choice anyone made. That box has not been rebooted into a decision since.

Half of them do not even own their key

This is the one I did not expect. A certificate is supposed to be unique, because the whole point is that it is bound to a private key only one machine holds. In this sample, 944 of the 1,908 hosts, just under half, serve a certificate that is byte-for-byte identical to at least one other host.

Byte-for-byte identical means the same private key. A server can only complete the TLS handshake if it holds the key that matches the certificate it presents, so if two machines present the identical certificate, two machines hold the identical key. Whoever has that key can impersonate every host that shares it. One of the keys in this set is on 149 separate hosts.

The spread tells you how it happens. The 149-host key is mostly one Turkish hosting provider: customers all booted the same Windows template with the certificate and its private key baked into the image, and none of them regenerated it. Another key covers 141 hosts across 26 unrelated networks, which is the signature of a product or appliance shipped with one hardcoded key for every unit. Different causes, same failure. A key that was meant to be held by one machine is held by a crowd, and a shared secret held by a crowd is not a secret.

Three stacks, nineteen hundred hosts

One more measurement, because it explains the shape of all of the above. Across 1,908 hosts there are only 77 distinct TLS fingerprints, and the three most common account for 79 percent of the sample. The exposed-RDP internet runs, in effect, three TLS stacks. The two post-quantum hosts sit in rare fingerprint clusters of their own, which is what a modern, deliberately configured box looks like next to a monoculture of defaults. For completeness: 37 hosts still protect themselves with a key below the 2048-bit floor, and 1,637, that is 86 percent, hand their internal Active Directory or DNS domain name to any unauthenticated scanner during the handshake, before anyone logs in.

What the three failures have in common

Put them together. The same scan found two hosts defending against a quantum computer, six hundred signing with hashes broken a decade or two ago, and nine hundred serving a key that is not theirs alone. The population underneath is 96 percent self-signed and 41 percent past its operating system’s support date, and almost all of it runs on three TLS stacks.

The post-quantum story and the SHA-1 story and the shared-key story are one story told three ways. Migration is not a wave that sweeps the internet. It is a thin front edge of operators who read the standard and turned the knob, trailing a long tail of machines running whatever shipped the day they were installed, down to the certificate the installer generated and the key it copied in from the template. The front edge was two hosts. The tail was nineteen hundred.

If you run infrastructure, the useful read is not “we should look at post-quantum.” It is: find the self-signed certificate your oldest box generated, check what it signed itself with, check whether the box next to it is serving the same one, and notice that it has outlived three Microsoft support deadlines while you were reading articles about 2035. The future threat is real. The past one already has working exploits, and half the doors use the same key.

None of this is exotic. The internet does not get upgraded. It gets left on.

Provenance

The measurements are Verified: read on 2026-10-28 from a single Shodan export of 1,914 exposed-RDP host records, 1,908 distinct addresses, crawl timestamps spanning 2026-09-28 to 2026-10-28, with 1,774 on port 3389. The analysis is a handful of short Python passes over the gzipped JSON, and the script plus its captured aggregate output are published at github.com/DannyBCarrJr/post-quantum-measured-lab. The raw per-host data is not published and will not be: it holds third-party addresses and hostnames, and redistributing Shodan host data is against their terms. The method and the aggregate counts are the reproducible part, so run your own query of the same shape and tell me if the shape of the result differs.

What that script reports, all Verified: 1,834 of 1,914 certificates self-signed; 611 signed with SHA-1 or MD5, none of them from a publicly trusted CA, the nine non-self-signed exceptions being two Active Directory CAs and seven embedded-device certs; 563 of the 602 weak-hash self-signed certs on end-of-life Windows, a 61 percent weak-hash rate there against 4 percent on current releases; 944 of 1,908 hosts serving a certificate byte-identical to another host, the largest shared key on 149 hosts across 10 networks and one key spanning 141 hosts across 26; 77 distinct TLS fingerprints with the top three covering 79 percent; 37 hosts below the RSA-2048 floor; 1,637 leaking an internal domain name before authentication; and two hosts, a floor rather than a census, offering a post-quantum hybrid key exchange, both still signing their certificates classically. End-of-life Windows is defined as Shodan’s eol-os tag or an operating-system string naming Windows 7, Vista, XP, Server 2008 or 2008 R2, or Server 2012 or 2012 R2. Server 2016 and later are treated as current, since Server 2016 is in extended support until 2027.

Two things are Reported, not measured here. The breaks: SHA-1’s practical collision is from the SHAttered work in 2017 and its first chosen-prefix collision from Leurent and Peyrin at USENIX Security 2020; MD5’s first practical collision is Wang and colleagues in 2004, and the forged browser-trusted CA certificate is Sotirov and colleagues in December 2008. The managed-web adoption figure, post-quantum client support above 60 percent in February 2026 from under 3 percent two years earlier, is from Cloudflare Radar. That Windows auto-generates the RDP self-signed certificate is documented by Microsoft as Event ID 1056; that older releases sign it with SHA-1 by default is not something I could find stated in a Microsoft document, so the mechanism is inferred from the correlation in the data, not cited.

Limitations, stated rather than buried. This is exposed RDP, not the web, so the numbers describe an unmanaged long tail and not the internet at large, which is the whole point of the Cloudflare contrast. The post-quantum count is a floor because Shodan records a key-exchange group only when its probe captures one. And the shared-key finding reads a shared certificate as a shared private key, which is sound because a server proves possession of the matching key during the handshake, but it counts keys shared within this sample and says nothing about keys shared with hosts the scan did not see.

If I have something here wrong, email the studio and I will correct it in place with a note saying what changed.

Sources