💾 Archived View for zaibatsu.circumlunar.space › ~solderpunk › phlog › more-on-gopher-and-crypto.txt captured on 2022-03-01 at 15:23:30.
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
More on gopher and crypto ------------------------- My recent post[1] about "why gopher needs crypto" received a very well-considered response[2] over at The Boston Diaries. The author (do I call you "the conman"?) rightly points out that the true challenge is not in actually conducting a gopher request/response transaction over a TLS connection, which in relatively trivial and has been done before. Rather, the core difficulty lies in the absence of any way to represent in a type-1 response that a particular gopher resource is accessible via TLS. A simple convention, following the lead of the web (*involuntary shudder*) would be to have e.g. port 70 correspond strictly to plaintext and port N (7070, 4370, or whatever else you like - there have been plenty of suggestions on the gopher-project mailing list over the years) correspond strictly to TLS. TLS-aware clients could use the appropriate connection depending on the port. The problem with this is that non-TLS aware clients will likely suffer some kind of breakage when following a menu item which points to a TLS port. This means in order to avoid breakage of old clients, one must only ever publically link to port 70 (Gophernicus has a hack in place to automatically generate server-internal links on port 70 or a designated TLS port depending on what kind of connection is being used, but this doesn't work for outgoing links). But if we do that, how do the newer TLS aware clients ever know that a server also supports TLS? This is by no means insurmountable - an off-the-cuff suggestion on how to work around would be to establish a convention that servers which also support TLS connections over port N will answer requests on port 70 for some well-known selector with a machine-readable response indicating "Yes, indeed, this server speaks TLS, on port N". TLS aware clients could request this selector from each server before following a link to that server for the first time, cache that response to disk and use TLS or not forever after. But solutions like this are a long way from being elegant or robust, and as long as gopherspace remains a mix of TLs aware and unaware servers and clients (and, to reiterate, I do not want the non-TLS servers to go away) we're going to be limited to hacks like this. That's part of the reason that I am increasingly advocating not for an actual attempt to upgrade gopher (which, after all, is not any more likely to succeed than Gopher+) but for some new protocol (heavily gopher-inspired, but unquestionably distinct) so that backward compatibility is not a concern and we can just make things simple and clean. I'm under no delusion that this new protocol would ever see widespread use, but who cares? Half as much use as traditional gopher has today would still make a small and interesting community viable. The conman suggests that creating a new protocol is to risk that we "start falling into HTTP territory". This is of course a very real risk, but I also very strongly believe that it is perfectly avoidable if we are sufficiently determined from day one to avoid it. To this end, I hope to think and write (and read, if anybody wants to join in!) more in the future not just about the shortcomings of gopher but very explicitly about what is right and what is wrong about HTTP and HTML. It's vitally important to identify precisely what features of the web stack facilitated the current state of affairs if we want to avoid the same thing happening again. [1] gopher://zaibatsu.circumlunar.space/0/~solderpunk/phlog/why-gopher-needs-crypto.txt [2] gopher://gopher.conman.org:70/0Phlog:2019/03/31.1