2018-03-01
___R_u_n_n_i_n_g__a__s_e_c_u_r_e__g_o_p_h_e_r__s_e_r_v_e_r___________

There have been several discussions on how to secure gopher
connections and servers over the years. [__20h__][0] seems to get
tired of this and has made a [proposal][1] to the gopher project
mailing list.

In essence this proposal wants to preserve backwards compatibility
where clients will speculatively throw a TLS handshake at a gopher
service. If that succeeds certificates get exchanged, encryption will
get negotiated etc.

A legacy server (one that does not provide TLS) will see the TLS
handshake and will respond with an error message. The client will
then repeat the request with plain old gopher.

He continues to give an example that would allow a migration path
towards secured servers with no code changes on the server part.

Clients of course would have to be written to be able to talk TLS.

__20h__ uses some neat tools in his example that will not require
any code added to an existing server implementation. [sslh][2] is my
favourite in this toolchain. A small wrapper around a port that
detects protocol handshakes by regexps and forwards them to the
appropriate port. The original intent for this tool is to allow ssh
and tls served on the same port. What a nice hack!

In the gopher scenario this could be used to divert the connection to
another port where stunnel will happily establish a TLS connection
and forward the payloads to the gopher server. If there is no TLS
handshake the connection would go directly to the gopher server.

As I understand the proposal there are several drawbacks to it.
First of all there is no protection against downgrade attacks,
because the client does not know whether a server should speak TLS.
In the proposal for initial connections a new 'gophers://' URI is
proposed to distinguish the user's intent. However after the first
connection this intent gets lost as selectors do not consist of an
URI but just server/port tuples.

Of course one could run force the client to expect secured
connections only but that contradicts the backwards compatibility
goal.

Further discussions on the list center around used port schemes and
whether a separate port would be enough to expect encrypted
connections.  This argument does not take into account that a lot of
servers are already running on some non standard port and that the
protocol itself is indifferent about that.

As for the downgrade attacks one could imagine a scheme were
fingerprints for servers are stored in DNS records for a server
similar to [RFC4255][3], which specifies this for ssh key
fingerprints.  This will add yet another layer of indirection of
course and client implementations will get even more complicated.

Also the open issues of how to handle certificates, chains of trust
and so forth are still up for discussion.

I am not sure how this will turn out. I get the feeling though that
tor hidden services (.onion URIs) would solve all this with much much
less effort.

Tor hidden services have the expected pub key in their name, will
provide encrypted and authenticated  end-to-end connections plus give
some anonymity properties.

But it is nice to see efforts in improving gopher!

___References_______________________________________________________

[0]: gopher://r-36.net:70/1/
[1]: https://lists.debian.org/gopher-project/2018/02/msg00025.html
[2]: https://github.com/yrutschle/sslh.git
[3]: gopher://gopher.rbfh.de:70/0/RFC/rfc4255.txt
_____________________________________________________________________

Disagree? Found a typo of bug? Please get in touch and tell me!