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!