I've written and worked on a few TLS implementations, so it wasn't terribly interesting to me. And I have to go to work tomorrow and solve real, modern CA problems :)

But in short, I wanted to use Go, and it doesn't support SSLv3, the SSLv2 Client Hello, or the 40-bit RC4-MD5 export-grade cipher suites which I wanted to support too.

I was more shocked that I managed to get stock OpenSSL to issue a certificate that worked. There's a number of things that didn't work there, too. You can find my scars in mkcert.sh in the repo. Perhaps all of this is worthy of a follow-up post.

I could have tried to get some old server running instead, but I wouldn't have wanted to deploy that on the internet, even on an isolated Fly VM.

They used a similar kind of custom (and flawed) TLS implementation in their game(s) which allowed signing new certificates after brute forcing.

The benefit to this is that users can now play these games without needing to burn a new CD with either the SSL certs swapped, or the code patched to dummy out the checks. A "retail CD" will simply work with private servers now.

I've also been on the other side of the fence, building a "retro internet" service [1] has meant trying to implement ancient SSL/TLS services for things and people that want to use them on the network.

Getting modern OpenSSL (aka what ships in Debian) to even accept these ciphers, let alone keys that short is an uphill battle. Understandably, they're disabled by default and (in Debian at least) the cipher support isn't even compiled into the binary! This requires building a custom OpenSSL to build Nginx against to serve ancient SSL.

Presumably for the OP this kind of work was either outside of their realm of knowledge, or simply "easier" to outsource to the slop machine. Though I hope the machine they're running their demo TLS implementation on is separated completely from their own network. Rolling your own crypto libraries is always a bad idea [2] and I doubt LLM's have "improved" that

[1] https://www.youtube.com/watch?v=cSJsGNIDjtc

[2] https://soatok.blog/2025/01/31/hell-is-overconfident-develop...

Looks like 70% of cloudflare requests are using post-quantum TLS! https://radar.cloudflare.com/post-quantum

Probably not too many, because anonymous political speech from 10+ years ago isn't that interesting. Punishing people a decade after the fact isn't very effective for anything.

The CADO-NFS page gives some benchmark results for 16 threads, suggesting the algorithm parallelises at least somewhat well.

The biggest thing I'm afraid of is that the generated scripts missed some entries, or otherwise mis-classified them, in particular whether it got the trust bits right for each root. I would put the chances of that having some errors relatively high.

But there's too many roots across too many browser installers, so I'm not going to confirm the Netscape UI matches what the extracted data says.

PGP (1991) was considered secure as it was considered not brute forceable. With 128 bits, it was considered military grade at the time and the US had an export restriction due to that. That might have been an incentive for GNU Privacy Guard. In France you had to give your private key to the government authority if an encryption system used anymore than 56 bits (as I recall, I don't remember the exact number).

Consumer hardware doing it in a couple of days in 2025 is roughly in line with Moore's Law extrapolations people were drawing at the time. The surprise isn't really the timeline. It's that someone did it as a weekend project rather than a nation-state effort.