* * * * *
It's still not easy adding crypto to gopher
I brought up gopher over TLS (Transport Layer Security) [1] on the gopher
mailing list [2] today, and I learned of at least two new methods one could
use to signal the use of TLS. They all have their issues though. So to recap
the methods (in no particular order):
Running gopher over TLS over a dedicated port (currently in use)
Older clients will still attempt to use TCP (Transmission Control
Protocol) to connect; this isn't enough of a signal to say “all these
ports are yours, except 743—attempt no TCP there.” So older clients
won't be able to connect, and could annoy operators with useless log
messages.
Adding a flag past the port value
Again, older clients will ignore this, and it could possibly break
the Gopher+ [3] protocol. This might not be that much of an issue, as
Gopher+ isn't that widely used to begin with.
Adding new gopher types for TLS
The the plus side, clients that don't understand the new types will
safely ignore them. On the other hand, this could potentially double
the number of valid gopher types. A variation on this would be to set
the MSB (Most Significant Bit) of the type character to indicate TLS,
but then you run the risk of using an undefined character, especially
given that the majority of gopher sites now return UTF (Unicode
Transform Format)-8 encoded characters, and setting the high bit will
generate invalid UTF-8, which will break any existing client written
in Python3.
A new type of protocol (currently in use)
This exists—it's called Gemini [4] and there are those who call for
TLS to be removed from Gemini (for a variety of mutually exclusive
reasons). Go figure.
Peek at the network stream for the TLS protocol(currently in use)
First off, the server would need to peek at the incoming packet to
determine if it's a TLS and if so, kick the connection over to the
TLS library du jour, otherwise, fall back to the TCP connection. This
can fail due to an adversary forcing a regular TCP connection by
filtering out the TLS traffic.
Signal TLS via the caps.txt file (currently in use)
There's not much documentation about caps.txt—there's an Internet
draft [5] that covers the format, but the actual specification seems
to be this file [6] from the creator of the specification. There is a
field for TLS, but as it was pointed out on the mailing list, this is
subject to a MITM (Man In The Middle) degridation attack to force non
TLS [7].
Use DNS (Domain Name System) SRV (SeRVice record) records
There are several issues with this one—the state of DNS libraries was
dismal enough that I wrote my own [8] about a decade ago. Things
might have improved since then, but this is something to keep in
mind. Also, this is too, subject to MITM attacks, only at the DNS
level, which is way easier to pull off.
Switch gopher to using TLS exclusively
Given this is a controversal topic for Gemini, I don't think this is
a viable solution for gopher at all.
I think that covers all the methods. I'm of the opinion that gopher over TLS
isn't worth the effort.
[1]
https://lists.debian.org/gopher-project/2021/12/msg00001.html
[2]
https://lists.debian.org/gopher-project/
[3]
gopher://gopher.floodgap.com:70/0/gopher/tech/gopherplus.txt
[4]
https://gemini.circumlunar.space/
[5]
https://datatracker.ietf.org/doc/html/draft-matavka-gopher-ii-02
[6]
gopher://gopher.floodgap.com:70/0/caps.txt
[7]
https://lists.debian.org/gopher-project/2021/12/msg00006.html
[8]
https://github.com/spc476/SPCDNS
Email author at
[email protected]