While I do agree that this person's attitude towards security is a little too cavalier, I also disagree with your characterization that his problem with TLS is that it is hard.
Gopher is designed as a very simple protocol any programmer is supposed to be able to implement themselves. Including TLS in the protocol will, by its very nature, break this. It will basically rob gopher of its purpose. I understand why that would be a disqualifying property for someone who cares about that purpose.
Perhaps what is needed is a simple standard API that wraps OpenSSL, GNU/TLS, mbed TLS, Polar SSL, et al - that covers a small set of standard use cases.[1]
It's not /hard/ using a library, but it's hard using it properly.
And unless you're a cryptographer, you ABSOLUTELY SHOULD NOT roll your own encryption, and even then you're likely to screw things up.
[1] I know PKCS#11 and friends try to do some of this, but no-one fully implements the entire standard(s), and no-one implements a standard set of features either ... which makes finding a provider and a client with overlapping feature sets somewhat interesting.
I've done some (proprietary) work in this area, and I think that it ought to be the way to go.
> And unless you're a cryptographer, you ABSOLUTELY SHOULD NOT roll your own encryption, and even then you're likely to screw things up.
I agree with this, but given this, how do you build a secure protocol that any programmer can implement themselves? Just saying "don't do it" will lead to posts like these that conclude that security might not be worth sacrificing the self-reliance. But this article also does offer some potential solutions, like tunneling the insecure protocol over a secure channel. I think that would be a better solution for this issue than the library you are proposing.
> Perhaps what is needed is a simple standard API that wraps OpenSSL, GNU/TLS, mbed TLS, Polar SSL, et al - that covers a small set of standard use cases.
You mean like libtls[1], the OpenBSD project's attempt at hiding the guts of LibreSSL/OpenSSL? I'm not sure how well it lends itself to swapping out the backend, however.
> unless you're a cryptographer, you ABSOLUTELY SHOULD NOT roll your own encryption
I feel like this should be qualified a bit:
* If you are not a cryptographer, then you absolutely should not roll your own encryption scheme
* If you are not a programmer, then you absolutely should not roll your own encryption implementation
That is: cryptographer(s) should be working closely with programmer(s) to both design and implement an encryption scheme. Anything else is how we get things like Heartbleed.
> Gopher is designed as a very simple protocol any programmer is supposed to be able to implement themselves.
Okay, but then it's not suited for use a modern internet in 2019 and should stay locked on private networks where it can delight hobbyists without risking users.
> It will basically rob gopher of its purpose. I understand why that would be a disqualifying property for someone who cares about that purpose.
What purpose is that? Listening to this phlog and its immediate social network, it doesn't seem like it makes much sense.
I'm sorry the reality of networking and cryptography offend your artistic sensibilities, but I'm going to maintain that if you are the kind of inconsiderate buffoon who tries to foist this stuff off on unsuspecting users who are less well-equipped to make informed safety-vs-ideology decisions, you're doing them a terrible disservice.
Gopher is designed as a very simple protocol any programmer is supposed to be able to implement themselves. Including TLS in the protocol will, by its very nature, break this. It will basically rob gopher of its purpose. I understand why that would be a disqualifying property for someone who cares about that purpose.