
Encrypting Gopher - luu
https://gopher.floodgap.com/gopher/gw.lite?gopher://tilde.team:70/0/~rain1/phlog/20190608-encrypting-gopher.txt
======
LeoPanthera
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.

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

~~~
LeoPanthera
Nothing fancy. Router runs pfSense. VPN uses OpenVPN.

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

~~~
codezero
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 :)

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

~~~
codezero
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 :)

------
cesarb
> 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".)

------
th0ma5
I like a lot the idea of using .onion URLs to encrypt plain text protocols
that at the very least support proxy and DNS.

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

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

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

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

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

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

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

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

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

