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

[James Mills]

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 at shortcircuit.net.au
W: prologic.shortcircuit.net.au

On Sun, Feb 12, 2017 at 9:24 AM, Matt Owen (Jaruzel) <jaruzel at jaruzel.com>
wrote:

> In article <EA996E69-9296-45FB-B5F6-BBE53926F791 at holviala.com>, kim-
> 80HoypwBpWdWk0Htik3J/w at 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 at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/gopher-project/attachments/20170212/e6c91c71/attachment.html>