A bit unfortunate that so many of the interesting bits were left to ai. I would've enjoyed some commentary on why the custom TLS implementation was necessary. Oh well.
Update: found this explanation in a comment at the top of the (surprisingly short) Go file in the linked repo:
The target client is Netscape Communicator 4.51 (both the 40-bit export build and the 128-bit US build) with its clock set to the year 2000.
Go's crypto/tls cannot help: it dropped SSLv3 in Go 1.14, never accepted the SSLv2-compatible ClientHello that Netscape 4 sends, and never had RC4-MD5 or the 40-bit export suites. So this file carries its own tiny SSLv3 server-side implementation on top of stdlib primitives (RSA PKCS#1 v1.5, RC4, DES, 3DES, MD5, SHA-1). The server key is 512-bit RSA so that export clients can encrypt the premaster secret to it directly, without a ServerKeyExchange.
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.
I bet all the certificate metadata shown in the „View a certificate“ popup window is vulnerable to cross-site scripting. Back then you probably wouldn’t get a <script> tag through a CA's review process and I found such a problem in Netscape's image „About page“ popup.
If it were vulnerable to XSS, why would you even want it properly signed by a CA?
People almost never inspect the certificates of working websites, the only time they might look at it is when it fails validation.
I actually do like to view certificates of working sites, because it can be interesting to see what's listed in the Subject Alternative Names field. It can lead to some interesting observations about what sites are linked.
Strange seeing how people have such a hard time seeing others using AI and seem to want to complain about it instead of just, well, asking AI why something was likely done a way. It works both ways my dudes, experts don’t need to explain every last detail, prompt a bot with the context until you understand.
From my prospective, the outputs of a bot aren’t the interesting bits, it’s the input prompt that should warrant more attention.
A while back I helped a friend (read: dumped a bunch of compute power into it) brute force the SSL keys for Sega's "Phantasy Star Online" Dreamcast game.
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
Wasn't intended as a "nerdswipe". Wrangling OpenSSL to actually work is a herculean task on a good day. Much less figuring out how to enable ancient crypto protocols within it
It's okay to "not know things". Computers are such an incredibly vast field that there's chunks of them that can simply be beyond some of us
> A while back I helped a friend (read: dumped a bunch of compute power into it) brute force the SSL keys for Sega's "Phantasy Star Online" Dreamcast game.
Is there anything published online about this? It looks like the Sylverant website still requires patching the game.
>>>a few odd coding decisions, such as rolling your own crypto (RNG)<<<
Let me give some context here. MaraDNS is a DNS server that’s been around for a very long time, since 2001. There has never been, in those 25 years, any security holes found having to do with the RNG code used by MaraDNS. MaraDNS originally used an AES variant for the RNG; when DJB found cache timing attacks a little over two decades ago, I revised the AES-based RNG code to minimize the impact of such impacts, making the code slower and more complicated. So, about two decades ago, I implemented a new RNG based on RadioGatún, an algorithm which isn’t vulnerable to cache timing attacks and, indeed, has no known attacks which break its cryptographic claims, even though those claims were made over two decades ago.
My code has been extensively audited by multiple AI-based security researchers, and while they found two minor issues with the DNS-over-TCP code in the recursive resolver, and a minor issue with the RFC8482 reply in the recursive resolver, no issues have ever been found with the RNG code in MaraDNS (except the issue with possible cache timing attacks I fixed myself after learning about them). [1]
In the same time period, OpenSSL has had a large number of security issues, security advisories, and so on. OpenSSL has had countless security holes and patches in the last two decades (Heartbleed, etc.); MaraDNS has had precisely 0 known issues with its RNG code in the same time period. If I had relied on OpenSSL to keep MaraDNS’s cryptography secure, it would had been exposed to many more attacks than it has, since the code I rolled myself ended up being far more secure than using the code in a third party library.
Point being, it is possible for someone to roll their own secure RNG. I wouldn’t do so in a corporate context, for the simple reason management often times puts unreasonable time constraints on developers, but for an open source project developed on my own timeline, it can be, in fact it has been very secure.
Also: I was never exposed to the Lastpass breach because, instead of using Lastpass, I rolled my own secure website password generator. [2]
Forget whether you "roll your own" or not, userspace RNGs are a bad idea. The advice to rely on getrandom or urandom is as much about the superior security properties of a kernel RNG as they are about whether you'll fuck up AES somehow.
Linux kernel crypto code has resulted in security issues, e.g. CVE-2026-31431.
The advantage of using a cryptographically secure stream cipher [1] is that we only need about 128-256 bits of good entropy to generate an arbitrary large number of secure random numbers, across multiple systems (e.g. MaraDNS has a native Windows port where /dev/urandom randomness is instead done with proprietary Windows API calls). It can even give us some level of protection on systems where the OS level random API is compromised: Some people are wary of RDRAND because they think Intel might actually use an insecure PRNG for the numbers, and Coldcard Bitcoin seed generators were compromised a little over a month ago because their version of /dev/urandom was completely insecure on some of their devices.
I don't grant the premise that per-transaction urandom reads are likely a meaningful expense to begin with but on modern Linux getrandom is a vDSO anyways. Even before the vDSO, getrandom was fast.
The application domain where this tends to get brought up as a problem is in large-scale simulation. I have no opinion about whether getrandom is fast enough for simulation, but here we're talking about cryptographic random numbers, not simply high-quality random numbers. If you want to use something like PCG for your simulations I won't dunk on you.
In addition to the overhead of a /dev/urandom read(), since my programs run in a chroot() sandbox, there’s the possibility that the file descriptor to /dev/urandom will no longer function—since chroot() is not part of POSIX, there’s no rigorous standard on how chroot() is supposed to behave with a given operating system.
getrandom() is another possible solution, but the problem with getrandom() is that it’s also not part of the POSIX spec, and my program needs to compile in an anally POSIX compliant system: While my programs use chroot() and setgroups(), both of which aren’t part of the POSIX spec, it has a configure time option to disable both chroot() and setgroups() so everything will compile as long as the underlying system follows POSIX.
The reason for this strict compliance with POSIX is because the changes to the C compilers (gcc and clang) between 2022 and 2026 made previous versions of MaraDNS have issues compiling everything, and, indeed, with these C23 changes to C compilers, unpatched djbdns no longer even compiles with a modern compiler. I changed everything to work with the new C23 spec, then I changed the compile flags to compile with a strictly compliant C99 compiler, but to get that to work, I had to make the program strictly POSIX compliant (with the exceptions of chroot() and setgroups()).
This way, should MaraDNS not compile in the future (remember: The post-C23 changes broke a lot of programs that used to compile just fine), it’s a bug with the compiler not following C99 and/or POSIX, and not a bug with MaraDNS.
Hence, my homegrown secure pseudo random number generator, so I can make strong random numbers while remaining POSIX compliant (we seed the PRNG before entering the chroot() sandbox). Of course, /dev/urandom is also not part of POSIX, but it’s on pretty much any modern *NIX, and trying to open /dev/urandom is not going to raise compile-time errors.
I don't think trading resilience for POSIX compliance is a good call, and I don't think "strong random numbers" is at all the right way to think about this problem.
The slop machine gives answers to your questions. It hallucinates so it's recommended to verify what it says. Shit in, shit out. If you have no idea whatsoever and can't use other sources to verify claims, well, get a different job I guess.
This entire comment section is almost entirely people bemoaning AI output, calling AI a "slop machine", and you posted your regressive religious screed against it as if it were something to be proud of, seemingly to the approval of others. nearly every comment section with AI involved is like this, and many comment sections where AI is not involved. It deserves pushback.
People are indeed proud of remaining humans and resisting becoming AI corp appendages that are lost in slop at their own expense. Get over it. Your pushback is exactly as religious.
Update: found this explanation in a comment at the top of the (surprisingly short) Go file in the linked repo:
The target client is Netscape Communicator 4.51 (both the 40-bit export build and the 128-bit US build) with its clock set to the year 2000.
Go's crypto/tls cannot help: it dropped SSLv3 in Go 1.14, never accepted the SSLv2-compatible ClientHello that Netscape 4 sends, and never had RC4-MD5 or the 40-bit export suites. So this file carries its own tiny SSLv3 server-side implementation on top of stdlib primitives (RSA PKCS#1 v1.5, RC4, DES, 3DES, MD5, SHA-1). The server key is 512-bit RSA so that export clients can encrypt the premaster secret to it directly, without a ServerKeyExchange.