The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Sunday, March 31, 2019

Why adding crypto to gopher isn't that easy

I'm talking about the fact that my hypothetical new protocol operated strictly over TLS connections - plaintext straight up wasn't an option. I am of the opinion that the widespread lack of encryption in gopherspace today is the protocol's biggest shortcoming, and I actually suspect that this point alone discourages some folks who would otherwise be on board from adopting it. …

We only need to add ubiquitous encryption to gopher to end up with the best of both worlds!

Now, let me be clear exactly what I mean by "adding encryption to gopher". I don't want to advocate anybody serving anything on port 70 which isn't backward compatible with standard gopher, because that would be a tragedy for the gopher community. And I also don't want plaintext gopher to disappear entirely, because it's great that something like gopher exists which can be utilised on 40 year old machines which are too slow to do effective crypto. What I would like is to see something new which is basically "gopher plus crypto, maybe a little more" appear alongside the existing options. Something which could be thought of as a "souped up gopher" or as a "stripped down web", depending on your perspective. Something which meant people weren't forced to choose between two non- overlapping sets of massive and obvious shortcomings but could just USE the internet for sharing static content in a non-awful way - whether that static content is "just" phlog posts, ASCII art or old zines, or whether it's serious political dissent, cypherpunk activism, sexually explicit writing or non-trivial free software development.

Why gopher needs crypto

As I metioned before, adding TLS to gopher is relatively straightforward, as it can be added between the TCP layer and the gopher layer with both clients and servers. That's the trivial part. The next step is to register the gophers: URI scheme, and to register a default TCP port number for the gophers: URI. This too, is trivial (it just needs to be done once by somebody).

What's not so trivial is shoehorning the “secure gopher” into the gopher index file. There's no real place for it. The “gopher index” file is a machine readable file that indicates the contents of a gopher server and it looks something like:

1This is a pointer to another siteHTthis-selects-the-fileHTgopher.conman.orgHT70CRLF
0About this siteHTabout-site.txtHTexample.comHT70CRLF
gOur LogoHTlogo.gifHTexample.comHT70CRLF
IOur office spaceHToffice.jpgHTexample.comHT70CRLF

The first character of each line is an indication of what to expect when retrieving the data, a “1” indicates a gopher index file (an example of which you see above), a “0” is a text file, a “g” is a GIF file and “I” is for other image types. This is followed by a human readable description meant to be displayed, followed by a “selector,” followed by the hostname and port number. There is nothing there to indicate “use TLS.” A flag could be added past the port value to indicate “use TLS when retrieving this data” but:

  1. old gopher clients won't see the flag (most will just ignore it) and try to connect without TLS—at best, the client just errors out and at worst, crash;
  2. it breaks gopher clients that actually use the enhansed gopher protocol (alternative link)—they will either error out at best, or at worst, crash.

One solution is to just say “okay, port 70 is plain text, any other port is TLS” but again, we're back to the problem with older gopher clients that don't understand this. Another solution that would work is to assign new “gopher types” (the “0”, “g”, “I”, “1” etc.) for a TLS connection. That just involves picking about two dozen new characters. Old gopher clients will ignore “types” they don't understand and new clients can use TLS. Unfortunately, it does mean that information about the connection type leaks out. HTTP doesn't have this problem because the http: (and https:) URI does not include what the link is, unlike the gopher: URI (or the linking information in the gopher index file) which does include what the link is.

So I think it comes down to picking your poison:

  1. potentially breaking old client;
  2. doubling the number of “types” to support;
  3. or even a new type of protocol entirely, but then you start falling into HTTP territory …

Update on Tuesday, September 28TH, 2021

There might be a fourth way, but I think it's a hack.

Update on Monday, Debtember 6TH, 2021

There are more than four ways to do this, but I don't think any are worth implementing.

Obligatory Picture

[The future's so bright, I gotta wear shades]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site:, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.