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