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

[James Mills]

So here's my attempt so far:
https://github.com/prologic/go-gopher/commit/48590e76b1c3fff4e96c5e383e03778688387eaa

Problem is clients like lynx just hang when trying to access TLS resources
:/


James Mills / prologic

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

On Sun, Feb 12, 2017 at 4:09 PM, James Mills <prologic at shortcircuit.net.au>
wrote:

> 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/20170213/a071ae06/attachment.html>