Re: TLS in Gopher

[Cameron Kaiser <spectre@floodgap.com>]

> The  idea  of  TLS  for gopher has come up again. With rising popularity
> people seem to want to push all HTTP principles  into  gopher.  Since  I
> have  control of geomyidae and some gopher clients for tryouts I want to
> propose the following to end the whole discussion:
> 
> Ideal way:
> 
> 	C->S: STARTTLS\r\n
> 	S->C: <TLS begins on both sides>
> 	C->S(in TLS): selector[\tsearch]\r\n
> 	S->C(in TLS): answer
> 
> Compatibility:
> 
> 	C->S: STARTTLS\r\n
> 	S->C: 3Some error .... (TLS on client side fails)
> 	# New connection
> 	C->S: selector\r\n
> 	S->C: answer

Although I would prefer gopher+TLS have a categorical port and only be
accessible that way, I don't object to probing/upgrading, as long as the
client is smart about it.

My personal preference is that the client also cache once a STARTTLS probe
has succeeded, and then start using port 7443 directly when it encounters
a menu item referencing that server again so that downgrade attacks are
minimized. (As a consequence, every gopher server implementing gopher+TLS
should support both STARTTLS upgrading on port 70, as well as always
offering always-encrypted connections on the so-far de facto port 7443.)

A CAPS key could also aid in service discovery, but that can be optional.

To be explicit, once the client knows the server is capable of STARTTLS,
then if it sees port 70 for that server in a menu item, it should
automatically substitute 7443 and immediately speak TLS on that port in
future connections. Other port numbers should not be assumed. I'm not
picky about the timeout. There could be a CAPS key for this too which
would be analogous to HSTS, if people desire.

Similarly, the client should stop probing a server after a certain number
of tries. This number should be greater than 1 in case a downgrade attack
succeeds, but failure should be cached relatively quickly to avoid spamming
logs on currently existing non-TLS servers. Again, I'm not picky about
this number, but the behaviour should have an upper limit.

This adds complexity to gopher+TLS, but since gopher+TLS servers and clients
are likely to be operating on more modern systems, I don't feel it is an
undue burden.

-- 
------------------------------------ personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser@floodgap.com
-- It is the business of little minds to shrink. -- Carl Sandburg -------------