
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">True about the MITM problem. HTTPS never had to worry about backwards compatibility because since HTTP/1.0 they had an extensible protocol while gopher is stuck with the original RFC (that's why "they" won - extensibility vs. fixed tree-like structure). Also HTTP/HTML links are relative while Gopher resources are always absolute - HTTP/HTML can link to "/foo/bar.html" and not worry about the domain and the protocol (or possible TLS/SSL) while Gopher always has to link to resource + domain + port and that leaves no room for extension flags.</div><div class=""><br class=""></div><div class="">Coming back to our problem we actually have two ways to refer to a Gopher resource:</div><div class=""><br class=""></div><div class="">* <a href="gopher://domain:port/Tresource" class="">gopher://domain:port/Tresource</a></div><div class="">* menu resource with type, domain and port</div><div class=""><br class=""></div><div class="">The URL scheme can easily be changed to gophers:// which tells the client that yes, this is really an TLS-enabled Gopher connection so no problem there. But once you load that menu you get a list of resources which include a domain (or IP) and a port number but there is absolutely no way of telling the client which resources should use TLS and which resources should use plaintext connections. Yes, we could decide that "port number NNN is *always* TLS but that's not portable and we don't have an offical port number. We could also decide that "since this connection to domain.dom:7777 was TLS then *all* connections to domain.dom:7777 should be TLS - but what about links to other domains? There would be no way of knowing if the client should use TLS or not, and there's no room in menus to include that information (and fiddling with menus breaks old clients).</div><div class=""><br class=""></div><div class="">In other words, we're screwed :D</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">- Kim</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 06 Feb 2017, at 13:24, Wolfgang Faust <<a href="mailto:wolfgangmcq@gmail.com" class="">wolfgangmcq@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class=""><div class="">The problem with checking the server's caps file is that it (at least partially) defeats the purpose of TLS--an attacker can MITM the caps file and force the connection to plaintext. (Of course, they could also have done the same to the originating menu.)<div dir="auto" class=""><br class=""></div><div dir="auto" class="">Rather than using a specific port, why not use a prefix on the hostname? Something like "TLS+<a href="http://example.com/" class="">example.com</a>", which isn't a valid hostname because of the symbol.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">This does have historical precedent--when https was introduced, how did they handle backward compatibility? (I'm young enough that I don't remember this.)</div><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Feb 6, 2017 2:00 AM, "Kim Holviala" <<a href="mailto:kim@holviala.com" class="">kim@holviala.com</a>> wrote:<br type="attribution" class=""><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also, forcing port NNN to be always TLS breaks menu links in old non-TLS browsers. Tha caps.txt method is better in that regard because menus can always point to non-TLS port and the client can then upgrade to TLS if it wants.<font color="#888888" class=""><br class=""><br class=""><br class="">- Kim</font><div class="m_5604088009697182858quote" style="line-height:1.5"><div class="quoted-text"><br class=""><br class="">-------- Original Message --------<br class="">Subject: Re: [gopher] Gophernicus 2.4 "Millennium Edition" released<br class=""></div><div class="quoted-text">From: Kim Holviala <u class=""></u><br class="">To: Gopher Project Discussion <u class=""></u><br class="">CC: <br class=""><br class=""><br type="attribution" class=""></div><blockquote class="m_5604088009697182858quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">Ugh.... I hate this mixed top- and bottom-posting.... but this stupid phone won't let me bottom-post.<br class=""><br class="">Anyway, yes, that is one thing I was thinking of - assume port NNN is always TLS. Problem is, we need a port allocation for that.<br class=""><br class="">- Kim</div><div class="m_5604088009697182858quote" style="line-height:1.5"><div class="quoted-text"><br class=""><br class="">-------- Original Message --------<br class="">Subject: Re: [gopher] Gophernicus 2.4 "Millennium Edition" released<br class="">From: James Mills <u class=""></u><br class="">To: Gopher Project Discussion <u class=""></u><br class="">CC: <br class=""><br class=""><br type="attribution" class=""></div><div class="elided-text"><blockquote class="m_5604088009697182858quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">Can we just assume TLS if the destination port in the menu is 73 for example?</div><div class="gmail_extra"><br clear="all" class=""><div class=""><div class="m_5604088009697182858gmail_signature" data-smartmail="gmail_signature"><span style="border-collapse:collapse;color:rgb(136,136,136);font-size:13px" class=""><br class=""><font face="arial, sans-serif" class="">James Mills / prologic</font><br class=""><br class=""><font face="arial, sans-serif" class=""></font><font face="'courier new', monospace" class="">E: <a href="mailto:prologic@shortcircuit.net.au" style="color:rgb(0,0,204)" target="_blank" class="">prologic@shortcircuit.net.<wbr class="">au</a></font></span><div class=""><span style="font-family:'courier new',monospace;color:rgb(136,136,136);font-size:13px" class="">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" class="">prologic.shortcircuit.net.<wbr class="">au</a><br class=""></div></div></div>

<br class=""><div class="gmail_quote">On Sun, Feb 5, 2017 at 2:16 AM, Kim Holviala <span dir="ltr" class=""><<a href="mailto:kim@holviala.com" target="_blank" class="">kim@holviala.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br class="">

> On 04 Feb 2017, at 12:11, Cameron Kaiser <<a href="mailto:spectre@floodgap.com" target="_blank" class="">spectre@floodgap.com</a>> wrote:<br class="">

><br class="">

>> The only remaining problem is to figure out a way to tell which connections<br class="">

>> are TLS and which are plaintext in gopher menus. Alternative is not to<br class="">

>> change menus at all and require the clients to read caps.txt first to see<br class="">

>> if there is a non-zero ServerTLSPort available for encrypted connections.<br class="">

>> That might actually be the most backwards-compatible method.<br class="">

><br class="">

> That would certainly seem the most reasonable approach to me.<br class="">

<br class="">

</span>I agree. I tried to come up with a way to add some kind of "encrypted or not" flag in the menus... but the existing servers and clients out there are *so* broken that I couldn't come up with a way that would not break things.<br class="">

<br class="">

Oh well. Some day I'll try to patch Lynx or something to work with gopher over TLS.<br class="">

<span class="m_5604088009697182858HOEnZb"><font color="#888888" class=""><br class="">

<br class="">

<br class="">

- Kim<br class="">

</font></span><div class="m_5604088009697182858HOEnZb"><div class="m_5604088009697182858h5">______________________________<wbr class="">_________________<br class="">

Gopher-Project mailing list<br class="">

<a href="mailto:Gopher-Project@lists.alioth.debian.org" target="_blank" class="">Gopher-Project@lists.alioth.de<wbr class="">bian.org</a><br class="">

<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project" rel="noreferrer" target="_blank" class="">http://lists.alioth.debian.org<wbr class="">/cgi-bin/mailman/listinfo/goph<wbr class="">er-project</a><br class="">

</div></div></blockquote></div><br class=""></div>

</blockquote></div></div></blockquote></div><br class="">______________________________<wbr class="">_________________<br class="">

Gopher-Project mailing list<br class="">

<a href="mailto:Gopher-Project@lists.alioth.debian.org" class="">Gopher-Project@lists.alioth.<wbr class="">debian.org</a><br class="">

<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project" rel="noreferrer" target="_blank" class="">http://lists.alioth.debian.<wbr class="">org/cgi-bin/mailman/listinfo/<wbr class="">gopher-project</a><br class=""></blockquote></div><br class=""></div></div></div>

_______________________________________________<br class="">Gopher-Project mailing list<br class=""><a href="mailto:Gopher-Project@lists.alioth.debian.org" class="">Gopher-Project@lists.alioth.debian.org</a><br class="">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project</div></blockquote></div><br class=""></body></html>