[gopher] TLS situation in gopher [was: Re: Gophernicus 2.4

[Kim Holviala]

On 12 Feb 2017, at 19:24, Matt Owen (Jaruzel) <jaruzel at jaruzel.com> wrote:

> It feels like we're conflating two thing here:
> 
> 1. Directing gopher clients to a secure connection for a resource.
> 2. Defining the TLS negotiation.

In my opinion #2 is not a problem at all - it can be done with a fixed TLS port, autodetected TLS-negotiation, STARTTLS, caps.txt or whatever. But #1 *is* a problem because pretty much any extra data inserted in menus will break some (stupid) clients.

> We could use the TLS syntax (as previously suggested), like so:
> 
> ... <port><TAB>TLS:<secure-port>  
> 
> This only runs the risk of breaking some badly built existing Gopher Plus 
> clients, but there are very few Gopher+ clients anyway, so the impact would be 
> minimal.

I think this is the best suggestion so far but the clients would still have to be tested. And this really needs to be an extensible "standard" so in the glorious steampunk future where everyone uses Gopher we could add more extra parameters to menus.

Still, this has a huge problem: all existing menus would need to be fixed to point to the TLS versions of the resources. And that will happen... like never, so the TLS-enabled version of the menu or resource would never really be requested.

> Until we define a standard TLS port, the URI scheme would be:
> 
>   gophers://<host>:<secure-port>/<selector>

I think no one disagrees with the gophers:// URI scheme? Good :)

[... having deep thoughts ...]

OK, a couple of facts:

* Old clients will never be replaced
* Old servers will never be replaced
* Old menus will never be fixed

This means that putting TLS-only content out there will make in unaccessible to a big chunk of the 20 people and one cat still using Gopher :D. So whatever content is out there *needs* to work with both TLS and non-TLS connections.

Second observation: since old clients will never be replaced we cannot link to TLS-only version of the resource in Gopher menus. Whatever links we have in menus need to retain the old non-TLS port number. This can be either handled with the above TLS: dual-port scheme or the way Gophernicus does it now - serving different port numbers in menus to unsecure and TLS connections (70 and 7070 currently @ gophernicus.org). Or perhaps by a caps.txt lookup (described below).

Third: I fear that *any* change in menus will break things. I tried to add features to Gopher a few years ago and miserably failed because of old clients and servers breaking left and right. In case anyone is wondering it was about offloading some processing to the server so you could nicely handle Gopher with 80-year old 8080 or 6502 or similar (charset conversions, word wrapping, media transcoding etc).

Fourth: Lots of servers cannot be rewritten for STARTTLS but they can be put behind Stunnel or similar TLS wrapper. But after wrapping the server doesn't know that it's behind TLS so it will still show port 70 in menus without any TLS: extension.

Having written all that, I still think the caps.txt method is the simplest of them all, doesn't break menus nor need fixing of all menus and doesn't affect old clients or servers in any way.

Non-TLS client, non-TLS server:
C: about.txt
S: <contents of about.txt>

Non-TLS client, TLS server:
C: about.txt
S: <contents of about.txt>

TLS client, non-TLS server:
C: caps.txt
S: plz go away type 3 omg omg
C: about.txt
S: <contents of about.txt>

TLS client, non-TLS server with TLS wrapper:
C: <connects to server:70>
C: caps.txt
S: ServerTLSPort: 7070
C: <connects to server:7070 using TLS>
C: about.txt
S: <contents of about.txt>

TLS client, TLS server:
C: <connects to server:70>
C: caps.txt
S: ServerTLSPort: 7070
C: <connects to server:7070 using TLS>
C: about.txt
S: <contents of about.txt>

Here the client caches the information (caps.txt really) that server:7070 is TLS and every connection to server:7070 should be made using TLS. The client should also upgrade all connections to server:70 to TLS server:7070 because the server told it so. This way no one has to fix the menus and servers can simply be TLS-enabled with a simple wrapper and manually added caps.txt, clients of course would still need new code to support TLS.



- Kim