Re: [gopher] TLS situation in gopher [was: Re: Gophernicus 2.4

James Mills / prologic

E: prologic@shortcircuit.net.au

On Sun, Feb 12, 2017 at 1:57 PM, James Mills <prologic@shortcircuit.net.au> wrote:

Matt I think this is the most well thought-out solution.

/me goes and goes this up in https://github.com/prologic/go-gopher

James Mills / prologic

E: prologic@shortcircuit.net.au
W: prologic.shortcircuit.net.au

On Sun, Feb 12, 2017 at 9:24 AM, Matt Owen (Jaruzel) <jaruzel@jaruzel.com> wrote:
In article <[🔎] EA996E69-9296-45FB-B5F6-BBE53926F791@holviala.com" target="_blank">EA996E69-9296-45FB-B5F6-BBE53926F791@holviala.com>, kim-
80HoypwBpWdWk0Htik3J/w@public.gmane.org says...
>
>Also, what should the response to STARTTLS be?
>
>C: opens TCP connection to server
>C: STARTTLS
>S: WTF OMG OMG IT'S ALIVE!!!!
>C: bzzzzz trrr trrr trrr <TLS connection with proper selector request here>
>S: Happily serving the request
>
>So what should server answer instead of WTF? Client needs to know the server
is
>OK with the connection, and the client should probably re-request without
>STARTTLS if the server doesn't understand TLS.
>

As we don't have prefix codes like HTTP and SMTP have, the best I can think of
is:

C: STARTTLS
S: STARTTLS OK <any extra info here, like version etc, prefixed by ':' >
C: bzzzzz trrr trrr trrr <TLS connection with proper selector request here>
S: Happily serving the request

It's incredibly unlikely that any legacy Gopher server will respond with
'STARTTLS OK'.

A correctly built server should return a '3' error, so the client trys again
without the STARTTLS request. My concern on this is that it would create added
latency before the menu or file is retrieved, on non TLS aware servers. a good
client should remember for that session, that server X does not support TLS,
so doesn't ask again.

I'm struggling to see a workable solution on the same port as non secure
traffic, that doesn't break legacy clients or servers, that also encrypts on
every request to the server (including the initial request).

So thinking afresh, I've come up with this...

At the end of the day, the client ALWAYS has to be the one to request TLS -
having it decode a previous server menu or file response first is simply not
secure.

It feels like we're conflating two thing here:

1. Directing gopher clients to a secure connection for a resource.
2. Defining the TLS negotiation.

Looking at #1 - This is where we try to find a non-breaking additonal syntax
to a selector line in a menu structure, that tells TLS aware clients to not
only 'go secure' but to use a different port for that selector. Technically,
we should be able to do that in the space where the Gopher+ syntax sits at the
end of the selector line, after the port. Therefore, conceptually, where a
Gopher plus line would end with:

... <port><TAB>+

We could use the TLS syntax (as previously suggested), like so:

... <port><TAB>TLS:<secure-port>

This only runs the risk of breaking some badly built existing Gopher Plus
clients, but there are very few Gopher+ clients anyway, so the impact would be
minimal.

Legacy Gopher clients should ignore anything after <port> and just carry on
non-securely, and TLS aware clients, will see the TLS:<secure-port> entry and
upgrade accordingly for the request to that selector. Which brings us to #2:

The client upgrades to TLS by connecting to the <secure-port>, and then
invoking the STARTTLS request, as per Kims suggestion. It can be assumed that
if the server is listening on this alternative port, then it *is* TLS aware,
and shouldn't error (but we can handle that anyway, when we define the
protocol).

For linking into remote sites via TLS we would do:

a. For Gopher server to Gopher server, the method described in #1 above.

b. For web page to Gopher Server we do this initially:
gophers://<host>/<selector>

TLS aware gopher clients will see the protocol is gophers:// and use the
'standard' TLS port [1].

Until we define a standard TLS port, the URI scheme would be:

gophers://<host>:<secure-port>/<selector>

These are just my thoughts on the matter, I am in no way dictating a
direction. :)

-Matt

---
[1] And to follow up on a previous post - we should *definately* approach IANA
to reserve a port number for GOPHER-TLS.

_______________________________________________
Gopher-Project mailing list
Gopher-Project@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project