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.

> While I haven’t verified this LLM output is entirely trustworthy, it looks pretty plausible.

It's essential that you do, because generating pretty plausible outputs is an LLM's bread and butter. Otherwise, only the one that you actually tested should be expected to be correct.