[gopher] Adding TLS and/or SSL support to Gopher

Discussion:

s***@sdf.org

2015-04-23 19:18:26 UTC

New thread for an important topic :)

Looking in my OS's /etc/services file it appears there are several
available ports in the 700-799 range:

# 703 Unassigned
# 708 Unassigned
# 717-728 Unassigned
# 703 Unassigned
# 708 Unassigned
# 717-728 Unassigned
# 732-740 Unassigned
# 743 Unassigned
# 745-746 Unassigned
# 755-756 Unassigned
# 766 Unassigned
# 768 Unassigned
# 778-779 Unassigned
# 781-785 Unassigned
# 786 Unassigned
# 787 Unassigned
# 788-799 Unassigned

As for implementation of the concept, I feel it should be done in a way
that doesn't shut out existing gopher clients/servers.

Perhaps adopting some sort of external client+server proxy model would be
the best starting point such that, for example, someone with a lynx(1)
browser could install a "secure_gopher" proxy on their computer such that
their now local port 70 requests are SSL-wrapped and sent on to a
corresponding "secure_gopher" proxy server listening on the new gopherS
TLS encrypted port (785 maybe?). Probably it's already doable using
opensshd and SOCKS, just need to pick a port.

The above approach would not preclude others from basically incorporating
the proxy model into their new clients and servers for an all-in-one
solution.

For making it officially part of Gopher World I think it means a new RFC
for "secure gopher" or at least adding the spec to the existing gopher
RFC; I don't know which would be easier.

Jeff / gopher://jgw.mdns.org

James Mills

2015-04-23 21:00:27 UTC

Permalink

I actually quite like this idea to start with :)

cheers
James

James Mills / prologic

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

Post by s***@sdf.org
New thread for an important topic :)
Looking in my OS's /etc/services file it appears there are several
# 703 Unassigned
# 708 Unassigned
# 717-728 Unassigned
# 703 Unassigned
# 708 Unassigned
# 717-728 Unassigned
# 732-740 Unassigned
# 743 Unassigned
# 745-746 Unassigned
# 755-756 Unassigned
# 766 Unassigned
# 768 Unassigned
# 778-779 Unassigned
# 781-785 Unassigned
# 786 Unassigned
# 787 Unassigned
# 788-799 Unassigned
As for implementation of the concept, I feel it should be done in a way
that doesn't shut out existing gopher clients/servers.
Perhaps adopting some sort of external client+server proxy model would be
the best starting point such that, for example, someone with a lynx(1)
browser could install a "secure_gopher" proxy on their computer such that
their now local port 70 requests are SSL-wrapped and sent on to a
corresponding "secure_gopher" proxy server listening on the new gopherS
TLS encrypted port (785 maybe?). Probably it's already doable using
opensshd and SOCKS, just need to pick a port.
The above approach would not preclude others from basically incorporating
the proxy model into their new clients and servers for an all-in-one
solution.
For making it officially part of Gopher World I think it means a new RFC
for "secure gopher" or at least adding the spec to the existing gopher
RFC; I don't know which would be easier.
Jeff / gopher://jgw.mdns.org
_______________________________________________
Gopher-Project mailing list
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project

Kevin Veroneau

2015-04-23 22:08:26 UTC

Permalink

I can help out with creating a client and server proxy for this. However I'm not sure how this will work. Here are my key concerns:

The Gopher protocol doesn't natively support proxy servers. So, connecting to localhost can only tunnel to a single remote gopher server...
Rewritting of gopher menus to change both the host and port will also be needed.

As a result, I don't think creating a TLS proxy would be feasible, let alone tunneling through an SSH or SSL tunnel.

The major issue with the gopher protocol is it's menus provide a host and port. While this is also a huge benefit to the protocol, it's also a hurdle when it comes to proxying the protocol itself. Thankfully the menus are easily parsable.

Post by James Mills
I actually quite like this idea to start with :)
cheers
James
James Mills / prologic
W: prologic.shortcircuit.net.au

way

Post by s***@sdf.org
that doesn't shut out existing gopher clients/servers.
Perhaps adopting some sort of external client+server proxy model

would be

Post by s***@sdf.org
the best starting point such that, for example, someone with a

lynx(1)

Post by s***@sdf.org
browser could install a "secure_gopher" proxy on their computer such

that

Post by s***@sdf.org
their now local port 70 requests are SSL-wrapped and sent on to a
corresponding "secure_gopher" proxy server listening on the new

gopherS

Post by s***@sdf.org
TLS encrypted port (785 maybe?). Probably it's already doable using
opensshd and SOCKS, just need to pick a port.
The above approach would not preclude others from basically

incorporating

Post by s***@sdf.org
the proxy model into their new clients and servers for an all-in-one
solution.
For making it officially part of Gopher World I think it means a new

RFC

Post by s***@sdf.org
for "secure gopher" or at least adding the spec to the existing

gopher

Post by s***@sdf.org
RFC; I don't know which would be easier.
Jeff / gopher://jgw.mdns.org
_______________________________________________
Gopher-Project mailing list

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

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Philipp Schafft

2015-04-24 02:40:19 UTC

Permalink

Good morning!

I'm not sure another port needs to be assigned.
Please see RFC2817 and RFC2818 as reference.
Also consider the way cups does it. Beside supporting RFC2817 it detects
TLS clients and can handle both kinds on the same port.

Post by s***@sdf.org
As for implementation of the concept, I feel it should be done in a way
that doesn't shut out existing gopher clients/servers.
Perhaps adopting some sort of external client+server proxy model would be
the best starting point such that, for example, someone with a lynx(1)
browser could install a "secure_gopher" proxy on their computer such that
their now local port 70 requests are SSL-wrapped and sent on to a
corresponding "secure_gopher" proxy server listening on the new gopherS
TLS encrypted port (785 maybe?). Probably it's already doable using
opensshd and SOCKS, just need to pick a port.
The above approach would not preclude others from basically incorporating
the proxy model into their new clients and servers for an all-in-one
solution.

I think using proxys will not improve the situation much:
you can already have that. Also it is prone to security problems such as
that the client is not aware of the TLS link. There are many known
attacks to such proxified setups.

Post by s***@sdf.org
For making it officially part of Gopher World I think it means a new RFC
for "secure gopher" or at least adding the spec to the existing gopher
RFC; I don't know which would be easier.

I would kind of implement it in a RFC that is considered an addition to
the existing one.

Two little notes:
* SSL is dead. There is no secure configuration left. So please
keep it to TLS.
* Vhosting should be kept in mind. Gopher doesn't really support
this but there is no reason not to use multiple hostnames for
the same server. In this case TLS is used this may become
relevant as certs may differ. See RFC2817 and RFC6066.

--
Philipp.
(Rah of PH2)

William Orr

2015-04-25 05:00:26 UTC

Permalink

Post by Philipp Schafft
Good morning!

CUPS/anything that uses STARTLS, etc.

Post by Philipp Schafft

you can already have that. Also it is prone to security problems such as
that the client is not aware of the TLS link. There are many known
attacks to such proxified setups.

I would kind of implement it in a RFC that is considered an addition to
the existing one.
* SSL is dead. There is no secure configuration left. So please
keep it to TLS.
* Vhosting should be kept in mind. Gopher doesn't really support
this but there is no reason not to use multiple hostnames for
the same server. In this case TLS is used this may become
relevant as certs may differ. See RFC2817 and RFC6066.

HTTP does this with Server Name Indication. That would be a good way to
approach the problem in gopher
(https://en.wikipedia.org/wiki/Server_Name_Indication).

I'd be happy to help implement this in some client/server as well.
LibreSSL has added their libtls family of functions, which aims to
reduce the difficulty of writing software that uses TLS. The API isn't
wholly stable yet, but it's a much better starting point than the
madness which is OpenSSL's API.

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

s***@sdf.org

2015-04-29 22:12:30 UTC

Permalink

Post by William Orr

Post by Philipp Schafft
* SSL is dead. There is no secure configuration left. So please
keep it to TLS.
* Vhosting should be kept in mind. Gopher doesn't really support
this but there is no reason not to use multiple hostnames for
the same server. In this case TLS is used this may become
relevant as certs may differ. See RFC2817 and RFC6066.

HTTP does this with Server Name Indication. That would be a good way to
approach the problem in gopher
(https://en.wikipedia.org/wiki/Server_Name_Indication).
I'd be happy to help implement this in some client/server as well.
LibreSSL has added their libtls family of functions, which aims to
reduce the difficulty of writing software that uses TLS. The API isn't
wholly stable yet, but it's a much better starting point than the
madness which is OpenSSL's API.

I'm not much of a coder but I'd be willing to help test things via
compiling and/or hosting test servers. My upstream bandwidth isn't great
but for gopher stuff it should be fine. Current gopherd is geomyidae[1]
running on VIA i386 system.

I hope some progress can be made with respect to adding encryption to
gopher; the rest of the Internet seems to be moving in that direction
and I think gopher risks further malignment if it remains strictly a
clear-text protocol.

Jeff / gopher://jgw.mdns.org

[1] gopher://gopher.r-36.net/1/geomyidae.gph

Philipp Schafft

2015-04-30 03:48:14 UTC

Permalink

reflum,

Post by William Orr

Post by Philipp Schafft
Good morning!

Oh, yes, morning it is. *can see the darkness slowly pushed away by the
dark blue that is on the eastward horizon even before the red of the
morning sun is approaching to welcome the new day*

Post by William Orr

Post by Philipp Schafft

CUPS/anything that uses STARTLS, etc.

On HTTP this is Upgrade+TLS [RFC2817]. It's more than just STARTTLS but
in this case doing the same. But CUPS does some more here: It can *also*
detect RFC2818 mode (HTTP-over-TLS) clients. I think this works by
detecting if the client sends a TLS or a HTTP request. May be a bit more
complicated to implement but is compatible with all modes on one
listening socket.

Post by William Orr

Post by Philipp Schafft

you can already have that. Also it is prone to security problems such as
that the client is not aware of the TLS link. There are many known
attacks to such proxified setups.

HTTP does this with Server Name Indication. That would be a good way to
approach the problem in gopher
(https://en.wikipedia.org/wiki/Server_Name_Indication).

HTTP itself does it via Host:-header. In case RFC2818 mode is used it
doesn't care at all about the transport (and therefore certs). In
RFC2817 mode it will also use the Host:-header to tell the server which
vhost you are connecting to. SNI [RFC6066] is TLS's way of solving it.
It is upper-layer agnostic and may be the better option for gopher.
Maybe a (to be written) RFC should declare SNI as a requirement for
clients. As this is defining something new there aren't many things we
need to take care of in terms of compatibility, so stuff like this could
be enforced by the RFC.

Post by William Orr
I'd be happy to help implement this in some client/server as well.
LibreSSL has added their libtls family of functions, which aims to
reduce the difficulty of writing software that uses TLS. The API isn't
wholly stable yet, but it's a much better starting point than the
madness which is OpenSSL's API.

I think implementation is a important task. Of cause. Yet I would love
to see a standard of some kind first. Otherwise we will end up with
multiple implementations that can't talk to each other or are only
compatible on a very basic level. (Do we want yet another standard
everybody 'interprets' in a completely different way?)

Have a nice day and thank you for reading and considering my input!

--
Philipp.
(Rah of PH2)

Ciprian Dorin Craciun

2015-04-30 08:50:45 UTC

Permalink

Post by s***@sdf.org
New thread for an important topic :)

[...]

Post by s***@sdf.org
As for implementation of the concept, I feel it should be done in a way
that doesn't shut out existing gopher clients/servers.

Sorry for barging in into the Gopher over TLS discussion, but I think
an important step was skipped, namely what is the expected outcome of
this move? (Which are its use cases?)

I've quickly looked through the initial thread and this one, and
besides a mention of "it would make Gopher more secure", and technical
impediments, I haven't seen even a rough analysis of its benefits and
(especially) costs.

From what I gather Gopher is mainly used for its simplicity, both in
writing servers or clients, and the fact that it is light in resource
consumption. Now adding TLS on-top of this, would certainly remove
the "lightness", and provide a "false" sense of security, because
implementing (or even using) cryptographic elements is quite tough.
(Just look at the number of issues stemming from SSL/TLS and its
integration in HTTPS.)

I would assume that the main use case would be to protect a small
number of resources from peering-eyes.

This can much easily be achieved with something like below:

* introduce a new resource type for "encrypted" resources; (granted
the selector is still in plain text, thus no private information
should be contained within;) (perhaps a new resource type for
"encrypted" menus?)

* make supporting servers expose a special resource which provides its
certificate; (in essence only the public key is needed;) (perhaps in
the capabilities resource?)

* when the client wants to use the selector of the encrypted resource,
it will instead derive a new selector which should contain, encrypted
towards the public key of the server, the actual selector and a random
token (see below on its usage), and perhaps some additional details
regarding the cryptographic technique the client would like to be used
for the resource data;

* the server would then encrypt the response with the random token and
the algorithm requested by the client;

* the server now returns this data, and the client (which has the
random token) can now decrypt the data;

* for better security one could instead use GnuPG, thus using PGP
public keys for the server, and all the rest of that ecosystem,
including signatures; perhaps using PGP public keys even on the
client side instead of the random token; thus all we are left with is
two PGP messages both ways, and all the server needs to do
cryptographic wise is to call GnuPG;

Voila:
* we don't break the protocol;
* we allow backward compatibility;
* servers which don't support this, but support some kind of CGI would
be able to support it for selected resources;

Disclaimer: I haven't done myself even a rough analysis of my
proposal above, but I think going with GnuPG is better for Gopher than
going with TLS.

Ciprian.