<div dir="ltr">So I've been coding this up for <a href="https://github.com/prologic/go-gopher">https://github.com/prologic/go-gopher</a> and so far so good.<div><br></div><div>lynx at least just throws a nice error with a resource listed on a different port with TLS (Gopher+) menu so far.</div><div><br></div><div>Still working on this...</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><span style="border-collapse:collapse;color:rgb(136,136,136);font-size:13px"><br><font face="arial, sans-serif">James Mills / prologic</font><br><br><font face="arial, sans-serif"></font><font face="'courier new', monospace">E: <a href="mailto:prologic@shortcircuit.net.au" style="color:rgb(0,0,204)" target="_blank">prologic@shortcircuit.net.au</a></font></span><div><span style="font-family:'courier new',monospace;color:rgb(136,136,136);font-size:13px">W: </span><a href="http://prologic.shortcircuit.net.au" style="font-family:'courier new',monospace;font-size:13px;color:rgb(0,0,204)" target="_blank">prologic.shortcircuit.net.au</a><br></div></div></div>
<br><div class="gmail_quote">On Sun, Feb 12, 2017 at 1:57 PM, James Mills <span dir="ltr"><<a href="mailto:prologic@shortcircuit.net.au" target="_blank">prologic@shortcircuit.net.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Matt I think this is the most well thought-out solution.<div><br></div><div>/me goes and goes this up in <a href="https://github.com/prologic/go-gopher" target="_blank">https://github.com/prologic/<wbr>go-gopher</a></div></div><div class="gmail_extra"><br clear="all"><div><div class="m_8394275258294230183gmail_signature" data-smartmail="gmail_signature"><span style="border-collapse:collapse;color:rgb(136,136,136);font-size:13px"><br><font face="arial, sans-serif">James Mills / prologic</font><br><br><font face="arial, sans-serif"></font><font face="'courier new', monospace">E: <a href="mailto:prologic@shortcircuit.net.au" style="color:rgb(0,0,204)" target="_blank">prologic@shortcircuit.net.<wbr>au</a></font></span><div><span style="font-family:'courier new',monospace;color:rgb(136,136,136);font-size:13px">W: </span><a href="http://prologic.shortcircuit.net.au" style="font-family:'courier new',monospace;font-size:13px;color:rgb(0,0,204)" target="_blank">prologic.shortcircuit.net.<wbr>au</a><br></div></div></div><div><div class="h5">
<br><div class="gmail_quote">On Sun, Feb 12, 2017 at 9:24 AM, Matt Owen (Jaruzel) <span dir="ltr"><<a href="mailto:jaruzel@jaruzel.com" target="_blank">jaruzel@jaruzel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In article <<a href="mailto:EA996E69-9296-45FB-B5F6-BBE53926F791@holviala.com" target="_blank">EA996E69-9296-45FB-B5F6-BBE53<wbr>926F791@holviala.com</a>>, kim-<br>
80HoypwBpWdWk0Htik3J/<a href="mailto:w@public.gmane.org" target="_blank">w@public.<wbr>gmane.org</a> says...<br>
><br>
>Also, what should the response to STARTTLS be?<br>
><br>
>C: opens TCP connection to server<br>
>C: STARTTLS<br>
>S: WTF OMG OMG IT'S ALIVE!!!!<br>
>C: bzzzzz trrr trrr trrr <TLS connection with proper selector request here><br>
>S: Happily serving the request<br>
><br>
>So what should server answer instead of WTF? Client needs to know the server<br>
is<br>
>OK with the connection, and the client should probably re-request without<br>
>STARTTLS if the server doesn't understand TLS.<br>
><br>
<br>
As we don't have prefix codes like HTTP and SMTP have, the best I can think of<br>
is:<br>
<br>
C: STARTTLS<br>
S: STARTTLS OK <any extra info here, like version etc, prefixed by ':' ><br>
C: bzzzzz trrr trrr trrr <TLS connection with proper selector request here><br>
S: Happily serving the request<br>
<br>
It's incredibly unlikely that any legacy Gopher server will respond with<br>
'STARTTLS OK'.<br>
<br>
A correctly built server should return a '3' error, so the client trys again<br>
without the STARTTLS request. My concern on this is that it would create added<br>
latency before the menu or file is retrieved, on non TLS aware servers. a good<br>
client should remember for that session, that server X does not support TLS,<br>
so doesn't ask again.<br>
<br>
I'm struggling to see a workable solution on the same port as non secure<br>
traffic, that doesn't break legacy clients or servers, that also encrypts on<br>
every request to the server (including the initial request).<br>
<br>
So thinking afresh, I've come up with this...<br>
<br>
At the end of the day, the client ALWAYS has to be the one to request TLS -<br>
having it decode a previous server menu or file response first is simply not<br>
secure.<br>
<br>
It feels like we're conflating two thing here:<br>
<br>
1. Directing gopher clients to a secure connection for a resource.<br>
2. Defining the TLS negotiation.<br>
<br>
Looking at #1 - This is where we try to find a non-breaking additonal syntax<br>
to a selector line in a menu structure, that tells TLS aware clients to not<br>
only 'go secure' but to use a different port for that selector. Technically,<br>
we should be able to do that in the space where the Gopher+ syntax sits at the<br>
end of the selector line, after the port. Therefore, conceptually, where a<br>
Gopher plus line would end with:<br>
<br>
... <port><TAB>+<br>
<br>
We could use the TLS syntax (as previously suggested), like so:<br>
<br>
... <port><TAB>TLS:<secure-port><br>
<br>
This only runs the risk of breaking some badly built existing Gopher Plus<br>
clients, but there are very few Gopher+ clients anyway, so the impact would be<br>
minimal.<br>
<br>
Legacy Gopher clients should ignore anything after <port> and just carry on<br>
non-securely, and TLS aware clients, will see the TLS:<secure-port> entry and<br>
upgrade accordingly for the request to that selector. Which brings us to #2:<br>
<br>
The client upgrades to TLS by connecting to the <secure-port>, and then<br>
invoking the STARTTLS request, as per Kims suggestion. It can be assumed that<br>
if the server is listening on this alternative port, then it *is* TLS aware,<br>
and shouldn't error (but we can handle that anyway, when we define the<br>
protocol).<br>
<br>
For linking into remote sites via TLS we would do:<br>
<br>
a. For Gopher server to Gopher server, the method described in #1 above.<br>
<br>
b. For web page to Gopher Server we do this initially:<br>
   gophers://<host>/<selector><br>
<br>
TLS aware gopher clients will see the protocol is gophers:// and use the<br>
'standard' TLS port [1].<br>
<br>
Until we define a standard TLS port, the URI scheme would be:<br>
<br>
   gophers://<host>:<secure-<wbr>port>/<selector><br>
<br>
<br>
These are just my thoughts on the matter, I am in no way dictating a<br>
direction. :)<br>
<br>
-Matt<br>
<br>
---<br>
[1] And to follow up on a previous post - we should *definately* approach IANA<br>
to reserve a port number for GOPHER-TLS.<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
Gopher-Project mailing list<br>
<a href="mailto:Gopher-Project@lists.alioth.debian.org" target="_blank">Gopher-Project@lists.alioth.de<wbr>bian.org</a><br>
<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project" rel="noreferrer" target="_blank">http://lists.alioth.debian.org<wbr>/cgi-bin/mailman/listinfo/goph<wbr>er-project</a><br>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div>