[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [gopher] TLS situation in gopher [was: Re: Gophernicus 2.4 "Millennium Edition" released]



On 06 Feb 2017, at 14:08, Christoph Lohmann <20h@r-36.net> wrote:
> 
> For the daemon situation we could go with the time: Listen for the first
> bytes and if it's a TLS handshake, go with TLS.

There is an existing standard for something like that and it's called STARTTLS. The problem with STARTTLS is that if no TLS handshake (or STARTTLS command) happens the connection is done without encryption in a way that does not notify the end-user. In other words, it's still possible to do MITM.

> You are already doing
> this hack for the proxy thing by checking for a special string, which is
> according to the gopher rfc invalid and could be a valid selector.

Thanks for noticing that - there's now a new option in Gophernicus (git repo version) to disable the proxy protocol completely.

> For the client side I propose the mentioned »gophers://« syntax, which
> tells the clients to try TLS on port 70. If it fails (handshake won't be
> answered right), retry unencrypted.

No, never do that. If a client wants TLS then the connection should never be downgraded to an unencrypted one *silently*.

> And something else I thought about is headers or extensions: A selector
> has to end in \r\n. Why don't we put extensions between \r and \n?

Because it breaks some clients. Trust me, I tried to do extensions to the Gopher protocol a few years ago but eventually had to scrap all of my code because it would always break something, somewhere.

Better way is to mess with the port number in menus:

0About this project     /about.txt      gophernicus.org 70
0About this project     /about.txt      gophernicus.org TLS:7070

But I'm quite certain some clients completely break down when handed a menu like that.

Anyway - I'm open for suggestions and will try to implement them in Gophernicus. The current TLS/SSL "implementation" was super simple and didn't break anything so I will be leaving that in - but it's only half a solution without a proper way to link to TLS-enabled gopher sites.


- Kim


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

Reply to: