Re: [gopher] Gophernicus 2.4 "Millennium Edition" released

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.)

Rather than using a specific port, why not use a prefix on the hostname? Something like "TLS+example.com", which isn't a valid hostname because of the symbol.

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.)

On Feb 6, 2017 2:00 AM, "Kim Holviala" <kim@holviala.com> wrote:

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.

- Kim

-------- Original Message --------
Subject: Re: [gopher] Gophernicus 2.4 "Millennium Edition" released
From: Kim Holviala
To: Gopher Project Discussion
CC:

Ugh.... I hate this mixed top- and bottom-posting.... but this stupid phone won't let me bottom-post.

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.

- Kim

-------- Original Message --------
Subject: Re: [gopher] Gophernicus 2.4 "Millennium Edition" released
From: James Mills
To: Gopher Project Discussion
CC:

Can we just assume TLS if the destination port in the menu is 73 for example?

James Mills / prologic

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

On Sun, Feb 5, 2017 at 2:16 AM, Kim Holviala <kim@holviala.com> wrote:

> On 04 Feb 2017, at 12:11, Cameron Kaiser <spectre@floodgap.com> wrote:
>
>> The only remaining problem is to figure out a way to tell which connections
>> are TLS and which are plaintext in gopher menus. Alternative is not to
>> change menus at all and require the clients to read caps.txt first to see
>> if there is a non-zero ServerTLSPort available for encrypted connections.
>> That might actually be the most backwards-compatible method.
>
> That would certainly seem the most reasonable approach to me.

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.

Oh well. Some day I'll try to patch Lynx or something to work with gopher over TLS.

- Kim

_______________________________________________
Gopher-Project mailing list
Gopher-Project@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project

_______________________________________________
Gopher-Project mailing list
Gopher-Project@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project