[gopher] TLS situation in gopher [was: Re: Gophernicus 2.4 "Millennium Edition" released]

[Christoph Lohmann]

Greetings.

Am 06.02.2017 um 12:24 schrieb Wolfgang Faust:
> The problem with checking the server's caps file is that it (at least
> partially) defeats the purpose of TLS--an attacker can MITM the caps file
> and force the connection to plaintext. (Of course, they could also have
> done the same to the originating menu.)
> 
> Rather than using a specific port, why not use a prefix on the hostname?
> Something like "TLS+example.com", which isn't a valid hostname because of
> the symbol.

I, as the geomyidae developer, have an interest in the TLS situation
too. I wanted to implement it, but there is no standard. If all gopher
daemon developers agree on something fixing the clients is the next step.

For the daemon situation we could go with the time: Listen for the first
bytes and if it's a TLS handshake, go with TLS. You are already doing
this hack for the proxy thing by checking for a special string, which is
according to the gopher rfc invalid and could be a valid selector. The
other solution is a dedicated port, but it will require standardisation
and someone going to IANA.

My proposal is this: Check for the first two bytes of a connection, if
they are Non-UTF8 (TLS handshake only allows the values of 0, 1, 2, 11,
12, 13, 14, 16, 20, 255 for the first byte, second byte is the beginning
of the length, which is 24 bit long and is very unlikely to be some
meaningful byte). If they are not UTF-8, call your SSL library with the
received bytes to negotiate TLS (version > 1.2?). This solves the server
side. Based on this value the CGI implementations (geomyidae uses
environment variables, so it would set »HTTPS« [for compatibility] and
»GOPHERS« for newer CGI scripts).

For the client side I propose the mentioned »gophers://« syntax, which
tells the clients to try TLS on port 70. If it fails (handshake won't be
answered right), retry unencrypted. While we are changing clients, add
some suggestion for the users to try TLS, when just »gopher://« is entered.

And something else I thought about is headers or extensions: A selector
has to end in \r\n. Why don't we put extensions between \r and \n?

Example:
C->S: /something\rheader:value;header:value;\n

The length is restricted by how much the gopher daemon is reading of
course. If it is implemented right, it should check for \n and \r and
throw away everything behind it. If we control the server side we could
establish a standard on how much should be read from the client before
aborting. Is 2048 bytes enough? If we make it longer (What's the biggest
cookie size in the web?) the cookie problem could be solved that way
too. It would mean state and porting web applications to the gopher world.

Here I have to add how I am cheating there in geomyidae. While
implementing CGI I implemented ?arg=value&arg=value. Every CGI will
receive those values, parsed by the server. It works excellent.

All of the above require testing clients and servers. Maybe if we create
some good index of all clients and servers for gopher, contact their
authors with patches, a jump into the 21st century for gopher is
possible. Everyone is welcome to add clients and servers to the gopher
lawn directory project. ;)

I don't like the caps.txt thing, it's like the hacks you have for the
web. It's two requests and extra configuration. I'm more the protocol
guy. It's a bit like the gopher+, which did only a half way and will
onyl get metadata, not interaction (POST, headers, cookies), which is
the main argument for using HTTP.

How are your comments on my proposals?


Sincerely,

Christoph Lohmann