Sorry for top-posting... stupid phone...<br><br>I don't see the point of gopher-over-TLS but I don't see the point of gopher either - super dumb protocol that is completely broken in almost every regard. And yes, http(s) does have structured menus, it's called WebDav.<br><br>Anyway, gopher is a nice hobby and since people kept asking for TLS I decided to give it a shot.<br><br>Back to TLS. Don't use TXT records for a hack like this because there already exists a standard DNS record for protocol/port probing: SRV records.<br><br>Related: HTTP/HTML relied on everyone fixing their links to get TLS/SSL and even now, 20 years later that situation is still completely broken (although HSTS is trying to fix that). So something like HSTS is also needed here, something to tell the clients they can upgrade existing links/menu resources from plaintext to TLS without everyone needing to change their servers and fix menus.<br><br><br>- Kim<div class="quote" style="line-height: 1.5"><br><br>-------- Original Message --------<br>Subject: Re: [gopher] Gophernicus 2.4 "Millennium Edition" released<br>From: Mateusz Viste <mateusz@nospam.viste.fr><br>To: gopher-project@lists.alioth.debian.org<br>CC: <br><br><br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br><br>While I'm not interested in TLS support myself (truly don't see the <br>point), I am wondering... why are you trying to imagine a STARTLS-like <br>mechanism that hard, or inserting weird stuff into menus, instead of <br>relying on a non-invasive method of achieving the same result? I'm afraid <br>that fiddling in *any* way with legacy gopher clients/servers is <br>dangerous, and will lead to side effects.<br><br>My proposition would be: leave the gopher protocol alone as it is. If you <br>really feel the need for gopher-over-ssl - sure, why not, but it needs to <br>be on a dedicated port, and the SSL client would need to actively look <br>for it through a specialized DNS query.<br><br>An SSL-enabled client would need to try resolving the TXT record attached <br>to the server's hostname. If found, it would scan it. If the TXT record <br>would contain something like this...<br><br>  IN TXT      "GTLS:433"<br><br>...it would know that it's possible to connect to the same host on port <br>TCP/433 and expect an SSL layer there, and automatically switch the url <br>to gophers://hostname:433<br><br>This way, there is no risk of breaking any legacy code. The downside is, <br>that you can't run several gopher-ssl instances on a single IP with <br>different ports - not sure it's that's much of a constraint, though. If <br>really bored, one could extend the concept to such atrocities:<br><br>  IN TXT      "GTLS70:433 GTLS71:434 GTLS72:435 ..."<br><br>Meaning "for the gopher resources published on port 70 of this server, <br>look at SSL port 433, for resources under port 71, look at SSL/434, etc".<br><br>An additional benefit of this solution is that the protocol itself <br>doesn't change at all - I only add a SSL layer on top of it. This means <br>that any existing gopher server would be able to serve SSL content - it <br>only requires putting an SSL proxy in front of it (stunnel from M. <br>Trojnara comes to mind immediately, but alternatives exist as well). <br>Also, any existing gopher client would be able to talk to a SSL server, <br>if only passed through a SSL wrapper.<br><br>Mateusz<br><br><br>_______________________________________________<br>Gopher-Project mailing list<br>Gopher-Project@lists.alioth.debian.org<br>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project<br><br></blockquote></div>