This. I see interest in Gopher again, but they way they talk about it, they want to talk shit on like Markdown (read; HTML) parsers and essentially turn it into the web over port 70; all because the web sucks. (It does though, so I’ll give them that.)
Gopher’s strength and charm (why we talk about it in the endearing sense today) is its simplicity. Basically having something like the web just without HTTP isn’t very interesting after all.
There’s some good threads on this on gopher phlogs arguing over what “simple” constitutes, what makes sense as a natural extention of the protocol and what feels like reverse engineering the web. The way Alex’s wiki page on encryption started feels very much like the latter to me. It was too much as soon as he started talking about adding persistent connections, which undermine the core principle of gopher. He eventually settles on adding TLS, though, which I think falls into a more natural fit. It’s easy to implement on both client and server and can fall back easily enough. It doesn’t fundamentally change the way you interface with gopher, just makes sure that anyone listening in the middle can’t read along. I like it!
Wanting to adhere to the core principles of gopher, but try saying persistent connections are useless when you’re not in a tight geographic area like gopher would’ve been when its core principles were conceived. (Basically: try living in Australia. Latency sucks.)
Yeah, TLS is simple - you just wrap the existing connection. It’s an easy adaption (either via stunnel or via adding a library) and fits other stateless protocols like HTTP fine.
I still maintain that the most gopher-ish way to support encryption is via public anonymous gopher proxies which take requests over plain gopher, encrypt them, and tunnel them to an exit node on the other side.
This means:
no existing clients need to be modified – even netcat still works fine, and produces plaintext results
the IP a request comes from is known only to one of the two proxies
The mechanics of implementing the encrypted gopher proxies is beyond me, unfortunately. (I made an attempt, but ultimately couldn’t figure out the tooling.)
…but this doesn’t protect against anyone snooping on your end of the connection? They still have, in plaintext, what server you connect to, your request, and the response. You don’t even need to be a nation-state, just some guy in a coffee shop with a laptop.
If this is part of your threat model, I recommend running a local encrypted gopher proxy on localhost and chaining it with a remote pair (preferably having a pair of remote proxies that are forwarding your encrypted stream).
encrypted gopher is a good idea, but this proposal seems a bit half baked. for one, a single item type isn’t enough to encrypt all of gopher. seems to me you’d need an encrypted version of each item type. 20h has spent a lot of time thinking about this, and his two suggestions seem more comprehensive:
From a comment:
This. I see interest in Gopher again, but they way they talk about it, they want to talk shit on like Markdown (read; HTML) parsers and essentially turn it into the web over port 70; all because the web sucks. (It does though, so I’ll give them that.)
Gopher’s strength and charm (why we talk about it in the endearing sense today) is its simplicity. Basically having something like the web just without HTTP isn’t very interesting after all.
There’s some good threads on this on gopher phlogs arguing over what “simple” constitutes, what makes sense as a natural extention of the protocol and what feels like reverse engineering the web. The way Alex’s wiki page on encryption started feels very much like the latter to me. It was too much as soon as he started talking about adding persistent connections, which undermine the core principle of gopher. He eventually settles on adding TLS, though, which I think falls into a more natural fit. It’s easy to implement on both client and server and can fall back easily enough. It doesn’t fundamentally change the way you interface with gopher, just makes sure that anyone listening in the middle can’t read along. I like it!
Wanting to adhere to the core principles of gopher, but try saying persistent connections are useless when you’re not in a tight geographic area like gopher would’ve been when its core principles were conceived. (Basically: try living in Australia. Latency sucks.)
Yeah, TLS is simple - you just wrap the existing connection. It’s an easy adaption (either via stunnel or via adding a library) and fits other stateless protocols like HTTP fine.
I still maintain that the most gopher-ish way to support encryption is via public anonymous gopher proxies which take requests over plain gopher, encrypt them, and tunnel them to an exit node on the other side.
This means:
The mechanics of implementing the encrypted gopher proxies is beyond me, unfortunately. (I made an attempt, but ultimately couldn’t figure out the tooling.)
…but this doesn’t protect against anyone snooping on your end of the connection? They still have, in plaintext, what server you connect to, your request, and the response. You don’t even need to be a nation-state, just some guy in a coffee shop with a laptop.
If this is part of your threat model, I recommend running a local encrypted gopher proxy on localhost and chaining it with a remote pair (preferably having a pair of remote proxies that are forwarding your encrypted stream).
encrypted gopher is a good idea, but this proposal seems a bit half baked. for one, a single item type isn’t enough to encrypt all of gopher. seems to me you’d need an encrypted version of each item type. 20h has spent a lot of time thinking about this, and his two suggestions seem more comprehensive:
the mailing list discussion on tls is also worth reading, to understand the tradeoffs of different approaches.