[gopher] Adding TLS and/or SSL support to Gopher

[Ciprian Dorin Craciun]

On Thu, Apr 23, 2015 at 10:18 PM,  <simple at sdf.org> wrote:
> New thread for an important topic :)
>
[...]
>
> As for implementation of the concept, I feel it should be done in a way
> that doesn't shut out existing gopher clients/servers.


Sorry for barging in into the Gopher over TLS discussion, but I think
an important step was skipped, namely what is the expected outcome of
this move?  (Which are its use cases?)

I've quickly looked through the initial thread and this one, and
besides a mention of "it would make Gopher more secure", and technical
impediments, I haven't seen even a rough analysis of its benefits and
(especially) costs.


>From what I gather Gopher is mainly used for its simplicity, both in
writing servers or clients, and the fact that it is light in resource
consumption.  Now adding TLS on-top of this, would certainly remove
the "lightness", and provide a "false" sense of security, because
implementing (or even using) cryptographic elements is quite tough.
(Just look at the number of issues stemming from SSL/TLS and its
integration in HTTPS.)


I would assume that the main use case would be to protect a small
number of resources from peering-eyes.

This can much easily be achieved with something like below:

* introduce a new resource type for "encrypted" resources;  (granted
the selector is still in plain text, thus no private information
should be contained within;)  (perhaps a new resource type for
"encrypted" menus?)

* make supporting servers expose a special resource which provides its
certificate;  (in essence only the public key is needed;)  (perhaps in
the capabilities resource?)

* when the client wants to use the selector of the encrypted resource,
it will instead derive a new selector which should contain, encrypted
towards the public key of the server, the actual selector and a random
token (see below on its usage), and perhaps some additional details
regarding the cryptographic technique the client would like to be used
for the resource data;

* the server would then encrypt the response with the random token and
the algorithm requested by the client;

* the server now returns this data, and the client (which has the
random token) can now decrypt the data;

* for better security one could instead use GnuPG, thus using PGP
public keys for the server, and all the rest of that ecosystem,
including signatures;  perhaps using PGP public keys even on the
client side instead of the random token;  thus all we are left with is
two PGP messages both ways, and all the server needs to do
cryptographic wise is to call GnuPG;

Voila:
* we don't break the protocol;
* we allow backward compatibility;
* servers which don't support this, but support some kind of CGI would
be able to support it for selected resources;


Disclaimer:  I haven't done myself even a rough analysis of my
proposal above, but I think going with GnuPG is better for Gopher than
going with TLS.

Ciprian.