Introduction
Statistics
Contact
Development
Disclaimer
Help
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___________
here have been several discussions on how to secure gopher
onnections and servers over the years. [__20h__][0] seems to get
ired of this and has made a [proposal][1] to the gopher project
ailing list.
n essence this proposal wants to preserve backwards compatibility
here clients will speculatively throw a TLS handshake at a gopher
ervice. If that succeeds certificates get exchanged, encryption will
et negotiated etc.
legacy server (one that does not provide TLS) will see the TLS
andshake and will respond with an error message. The client will
hen repeat the request with plain old gopher.
e continues to give an example that would allow a migration path
owards secured servers with no code changes on the server part.
lients 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
ny code added to an existing server implementation. [sslh][2] is my
avourite in this toolchain. A small wrapper around a port that
etects protocol handshakes by regexps and forwards them to the
ppropriate port. The original intent for this tool is to allow ssh
nd tls served on the same port. What a nice hack!
n the gopher scenario this could be used to divert the connection to
nother port where stunnel will happily establish a TLS connection
nd forward the payloads to the gopher server. If there is no TLS
andshake the connection would go directly to the gopher server.
s I understand the proposal there are several drawbacks to it.
irst of all there is no protection against downgrade attacks,
ecause the client does not know whether a server should speak TLS.
n the proposal for initial connections a new 'gophers://' URI is
roposed to distinguish the user's intent. However after the first
onnection this intent gets lost as selectors do not consist of an
RI but just server/port tuples.
f course one could run force the client to expect secured
onnections only but that contradicts the backwards compatibility
oal.
urther discussions on the list center around used port schemes and
hether a separate port would be enough to expect encrypted
onnections. This argument does not take into account that a lot of
ervers are already running on some non standard port and that the
rotocol itself is indifferent about that.
s for the downgrade attacks one could imagine a scheme were
ingerprints for servers are stored in DNS records for a server
imilar to [RFC4255][3], which specifies this for ssh key
ingerprints. This will add yet another layer of indirection of
ourse and client implementations will get even more complicated.
lso the open issues of how to handle certificates, chains of trust
nd so forth are still up for discussion.
am not sure how this will turn out. I get the feeling though that
or hidden services (.onion URIs) would solve all this with much much
ess effort.
or hidden services have the expected pub key in their name, will
rovide encrypted and authenticated end-to-end connections plus give
ome anonymity properties.
ut 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
____________________________________________________________________
isagree? Found a typo of bug? Please get in touch and tell me!
