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