For a few years now I've been using my router to forward a selection of ports corresponding to commonly unencrypted protocols such as HTTP (80) and Gopher (70) through a VPN that terminates in a box I own hosted at a colo.
It improves the security of your data from your ISP, but has less of a performance impact than putting your entire internet connection through a VPN, increasingly so as more and more stuff moves to HTTPS/443.
I suppose it's possible that my colo is just as interested in intercepting my data as my ISP is. But my ISP is Comcast, so I doubt it.
Though having it in another country entirely might be beneficial as well.
Even if an encryption algorithm is decided on and widely adopted, clients will need to be updated to use it, meaning compatibility for older clients (which happens to be one of Gopher's core strengths, try surfing the modern web on NCSA Mosaic for a day) will be tarnished.
As it stands, I can use Gopher comfortably on Mac OS 9 with Cyberdog, Windows 95 with WSGopher32, old Java-based phones, and apparently on the Commodore 64, but yet also a high-speed broadband connection on my PC and Android phone. Trying to enforce some security standard on the entirety of Gopherspace will mean the earlier hardware will be more obsolete than they're already considered to be.
As an example Floodgap has weather information, feeds, xkcd strips, a Figlet gateway and Gopher link shortener, file archives for classic Macintosh software in particular, among others. And that's just Floodgap's server, elsewhere there are independent phlogs (blogs over Gopher), text adventure games (mozz.us), music, more files..
It may seem obsolete but there's a passionate community behind it. It just looks like that since it doesn't have wide-spread encryption and most clients have tried to treat gopher menus just as basic web pages. Although you can do that, it really limits what clients can do; I could drag mp3 files out of a Gopher menu onto my desktop with Cyberdog, and no client quite like that has come for modern systems (yet), nor can you do that with a webpage. I believe Gopher should be thought of as an improved anonymous FTP rather than a stripped down Web.
The author of that post missed BGP hijacking. (There's also NSA-style interception of the backbone links, but that's probably what the author considers "not a real life instance".)
I'd be curious about a specific example of this.
Yes. It is really a problem for people who use public networks. It is not like the myriad of wifi mitm attacks went away over the last 5 years. Even if you're not concerned about hiding the content, SOME sort of integrity scheme needs to be in place to prevent folks from replacing your content with theirs.
It seems profoundly irresponsible to wave away these concerns just because TLS is intimidating.
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.
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.
 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.
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.
You mean like libtls, 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.
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.
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.
If your modern internet is incapable of allowing for this, it kind of sucks.