Encrypting Gopher | Hacker News Reader

Encrypting Gopher

gopher.floodgap.com

82 pointsluu24 comments

My threat model for encryption is my ISP. If interception happens after that, my default assumption is that I have bigger problems.

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.

I'm curious to learn more about your setup! Would you be willing to share more here? Cheers!

Nothing fancy. Router runs pfSense. VPN uses OpenVPN.

Just adding, it's generally worth it to have such servers relatively close to your own network/physical location if you are concerned about performance.

Though having it in another country entirely might be beneficial as well.

One issue I have with rolling out a new form of encryption to replace the current Gopher protocol is that old clients will become obsolete and less useful.

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.

If you don’t mind me asking what kind of content do you consume on gopher? I had no idea it was still in regular use :)

As a general rule, if it's a file you can serve it over Gopher. And Gopher's query selector type (`?`) can be used for searching and simple applications.

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.

Thanks a bunch for the detail, I'm pretty familiar with Gopher as a thing, just didn't realize it still had a sort of vintage hobbyist following and that brings me great joy to hear :)

> Well, to my knowledge there's only really 2 real life instances you need to worry about (I'd welcome corrections if networking people can tell me about something I missed):

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 like a lot the idea of using .onion URLs to encrypt plain text protocols that at the very least support proxy and DNS.

You can achieve something similar with Zerotier's ipv6 addresses. You only get encryption but no privacy though.

> To keep in the spirit of gopher we should figure out a simple encryption system that a normal programmer can implement in a weekend. This is totally possible to do with strong security

I'd be curious about a specific example of this.

I assume they mean a system that uses existing crypto algorithms, rather than building everything completely from scratch. For example, if the system involves a key exchange, followed by the derivation of a shared secret, followed by symmetric encryption, all of these steps could use existing solutions with multiple available implementations (DH+AES, or perhaps X25519+ChaCha20). Wiring existing algorithms together to form a secure protocol is certainly doable by a competent programmer in a weekend. And in the Gopher spirit, if you really want to implement ChaCha20 yourself, that's much more tractable than implementing all of TLS.

Seems to me, the gopher thing to do would be to add a new type, eg E, for an encrypted file.

Maybe use OpenBSD’s signify for validation of content. S is unofficially used for sound files sadly...

I'm struggling not to find this article a bit offensive, if I'm honest. Essentially the author has said, "TLS is hard, and I don't use public networks so is it really a problem?"

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.

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.

[1] https://man.openbsd.org/tls_init

> 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.

Its purpose is having a communication protocol, so simple anybody can implement it themselves.

If your modern internet is incapable of allowing for this, it kind of sucks.

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.

Reply on news.ycombinator.com