Re: TLS in Gopher
Greetings,
On Thu, 01 Mar 2018 12:43:53 +0100 "Iain R. Learmonth" <irl@fsfe.org> wrote:
> Hi,
>
> On 28/02/18 05:48, Christoph Lohmann wrote:
> > I propose that we should introduce »gophers://« schema which tells the
> > client to use »secure mode« for digging through gopherspace.
>
> Gopher menus do not use URLs so it's impossible to link to such a
> resource. It also creates a division between "secure" and "insecure"
> gopherspace where resources are not the same as they have different URLs.
You are wrong here. In my daily gopher usage my entry to gopherspace is
always some URI. On IRC URIs are exchanged and then given to the client
via some plumbing. After that this client session is started and fur‐
ther navigation hap‐ pens.
In my e‐mail further below I describe why I propose gophers://, which is
to tell the client to use a secure mode. The secure mode is then de‐
scribed below and is in conclusion just TLS probing. I did not want to
define the »TLS«, how it has to be implemented since this is a moving
target. All of this complexity should lie in the TLS library used. For
full security of course DNSSEC + DANE is needed or something likewise to
check fingerprints from a second source. But this is part of TLS, not
gopher.
I do not want to change the menu layout, since there is no advantage we
get. Why should there be a distinction in defined menus? It will make
development of applications using gopher menus harder. Instead if your
entry to gopherspace was marked to use secure mode and the client sup‐
ports it, the probing is done – automatically. Everyone hosting some old
gopher content will automagically have secure mode available, without
modification.
This is why having a distinct port for gophers is useless. I want to run
gopher and TLS on every port available, not just 7443 or what we define.
> This is, specifically, the thing that I would least like to see in the
> implementation of TLS for Gopher. Please stop looking at things that
> already exist that have known problems and instead think about solving
> those problems. These problems would be a lot more problematic in Gopher
> due to the lack of use of actual URLs.
As said above: I proposed exactly what you said in further e‐mails: Sim‐
ple TLS probing, TLS implementation is client‐side and backwards compat‐
ibility to the old gopher. For me the URI is a mark – as said in my pre‐
vious e‐mail.
With the proposal you can not just tell the client how to interpret the
content:
gopher://bitreich.org/I/stateless-misra.png
vs.
gopher://bitreich.org/0/stateless-misra.png
but also to try secure mode:
gophers://bitreich.org/I/stateless-misra.png
If probing is turned on by default by the client it is not needed. I
want to give freedom, not restriction.
Btw., for any incompatibility or »split« you are concerned about. If
someone wants content to only be served over TLS, then the plain old go‐
pher client will get an error, if the gopher server is implemented cor‐
rectly. We use a principle not known in the web world anymore: Inform
the user in plain text.
»Sorry, this content is only served using TLS. Please see ... for
details on TLS over gopher.«
Sincerely,
Christoph Lohmann
Reply to: