[gopher] Gophernicus 2.4 "Millennium Edition" released

[Wolfgang Faust]

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 at 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 at shortcircuit.net.au
W: prologic.shortcircuit.net.au

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

>
> > On 04 Feb 2017, at 12:11, Cameron Kaiser <spectre at 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 at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project
>


_______________________________________________
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/20170206/4020be67/attachment-0001.html>