* * * * *

                 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]