Monday, Debtember 06, 2021
It's still not easy adding crypto to gopher
I brought up gopher over TLS on the gopher mailing list 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 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+ 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 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-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 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.txtfile (currently in use) - There's not much documentation about
caps.txt—there's an Internet draft that covers the format, but the actual specification seems to be this file 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 degridation attack to force non-TLS. - Use DNS SRV records
- There are several issues with this one—the state of DNS libraries was dismal enough that I wrote my own 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.
My blog on gopher is still a second class citizen, but it's getting better
Speaking of gopher, I've made it clear that the gopher version of my blog (as well as the Gemini version of my blog) are second class citizens. Since my last post on this matter, the formatting has improved a bit, but it's not quite there yet (the gopher version is okay at best, but the gemini version could use more work—more on that some other time).
But one thing that has improved is better support for displaying multiple posts. Granted, that feature is not used as much as I thought it would be, but I still wanted gopher and Gemini support. It took a bit of time, but I was able to get it working so now you can view my recent Brevard trip on one page on the web, on gopher, and on Gemini. And now in reverse chronological order: web, gopher and Gemini (well, you could always do reverse on the web since the beginning, it's just now I have support for the other two protocols).
All that's left is really thinking about reformatting the posts when “publishing” for gopher and Gemini …
