From: "Gopher-Project" <gopher-project-bounces+rachael=telefisk.org@lists.alioth.debian.org>
       Date: Thu Apr 30 05:49:03 2015
       Subject: Re: [gopher] Adding TLS and/or SSL support to Gopher
       
       --===============0340006011228582302==
       Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-OKmLIm/wqLhNzHLiWlST"
       
       --=-OKmLIm/wqLhNzHLiWlST
       Content-Type: text/plain; charset="ISO-8859-15"
       Content-Transfer-Encoding: quoted-printable
       
       reflum,
       
       On Fri, 2015-04-24 at 22:00 -0700, William Orr wrote:
       > On 4/23/15 7:40 PM, Philipp Schafft wrote:
       > > 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*
       
       
       > > On Thu, 2015-04-23 at 12:18 -0700, simple@sdf.org wrote:
       > >> 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
       > >=20
       > > 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 detect=
       s
       > > TLS clients and can handle both kinds on the same port.
       >=20
       > 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.
       
       
       
       > >> As for implementation of the concept, I feel it should be done in a wa=
       y
       > >> 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 t=
       hat
       > >> their now local port 70 requests are SSL-wrapped and sent on to a
       > >> corresponding "secure_gopher" proxy server listening on the new gopher=
       S
       > >> 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 incorporat=
       ing
       > >> the proxy model into their new clients and servers for an all-in-one
       > >> solution.
       > >=20
       > > I think using proxys will not improve the situation much:
       > > you can already have that. Also it is prone to security problems such a=
       s
       > > that the client is not aware of the TLS link. There are many known
       > > attacks to such proxified setups.
       > >=20
       > >=20
       > >> For making it officially part of Gopher World I think it means a new R=
       FC
       > >> for "secure gopher" or at least adding the spec to the existing gopher
       > >> RFC; I don't know which would be easier.
       > >=20
       > > I would kind of implement it in a RFC that is considered an addition to
       > > the existing one.
       > >=20
       > >=20
       > > 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.
       >=20
       > 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.
       
       
       > 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!
       
       --=20
       Philipp.
        (Rah of PH2)
       
       --=-OKmLIm/wqLhNzHLiWlST
       Content-Type: application/pgp-signature; name="signature.asc"
       Content-Description: This is a digitally signed message part
       
       -----BEGIN PGP SIGNATURE-----
       Comment: Because it's your freedom
       
       iQEcBAABAgAGBQJVQaX8AAoJEAAfMmx/9hlkiywH/1DPg4vtzkV1ps300i9z4naJ
       /qhhE5FWSI5elu26uKIpiBK9ulnwgnnUGALiN89+WgYrquRdgP4hx9wiBe4Glvgc
       HtcuiGBPvAl78F7mXJtCpQeKOdweno1yAUBVn0r+C5FKLLOkGbjo25l47MpZqhNs
       aTW6kjZKMcgjzDyLgaBcT1vzAB7zQ7G5VbVjHf/VwTznhYgMOGrQ9NRaj4GZCVtq
       r/iaFMDKAp2zWVJw/3zsS/uOLRZmZbblOaY4Uf/BMb+9dOcRVrV8GEq1G5Lh3Ywk
       AvVlOJK0Wk9rMomTrzTlszXoaB5jIAYzTEfwLdW0/iSBiU06JHfKJOOCGJugJew=
       =X4sg
       -----END PGP SIGNATURE-----
       
       --=-OKmLIm/wqLhNzHLiWlST--
       
       
       --===============0340006011228582302==
       Content-Type: text/plain; charset="us-ascii"
       MIME-Version: 1.0
       Content-Transfer-Encoding: 7bit
       Content-Disposition: inline
       
       _______________________________________________
       Gopher-Project mailing list
       Gopher-Project@lists.alioth.debian.org
       http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project
       --===============0340006011228582302==--
       Thread start
 (DIR) [gopher] Adding TLS and/or SSL support to Gopher
 (DIR) Followup: Re: [gopher] Adding TLS and/or SSL support to Gopher
 (DIR) Followup: Re: [gopher] Adding TLS and/or SSL support to Gopher
 (DIR) Followup: Re: [gopher] Adding TLS and/or SSL support to Gopher