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

[James Mills]

So I've been coding this up for https://github.com/prologic/go-gopher and
so far so good.

lynx at least just throws a nice error with a resource listed on a
different port with TLS (Gopher+) menu so far.

Still working on this...


James Mills / prologic

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

On Sun, Feb 12, 2017 at 1:57 PM, James Mills <prologic at 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 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/854dc67a/attachment-0001.html>