SSL Sucks and Crypto Isn't Hard

Ok, I'm three weeks into building a Gemini server. The actual protocol logic took me all of twenty minutes to implement. Binding that protocol logic to a daemonizable executable took five. Writing project documentation and setting up a public issue tracker took fifteen.

But three weeks in, I still don't have a usable server...because of SSL.

In the SSL space, you have two options: Write an insecure application from scratch in C, or bind to OpenSSL. Both options suck. OpenSSL really sucks. SSL as a system, sucks.

I don't have time to parse out my own thoughts on this and transpile them, so I'll just paste what a friend of mine who works professionally as a security researcher had to say after I showed him the Gemini FAQ, section 2.8:

> Okay I can refute all of these points:

> - Yes, there are bindings. But TLS is still nontrivial to get right - you either let the library terminate your connections and get very little control over the flow of data, or you terminate your own connections and have to deal with shuttling data back and forth, dealing with certificate failures and stuff, etc. on your own. Plus, pretty much all of those libraries require a nontrivial amount of non-obvious manual configuration in order to be remotely secure.

> - I disagree with "many developers are familiar with TLS", beyond as a PKI system

> - Yeah, users are already sort of trusting TLS. But non-cryptographers don't give a shit, and cryptographers will tell you that TLS is a total mess. So...

> - TLS may be "deeply entrenched", but... first of all, so is HTTP and HTML, and the deliberate goal of this project is to get away from the entrenched, bloated existing standards and create new ones; and because it's entrenched, it's difficult to correct its flaws. This whole line of reasoning comes from a "crypto needs to be hard" background, whereas crypto absolutely does not need to be hard; it's only hard if you use a piece of garbage like TLS.

Gemini should have used Noise from the start.