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

Re: Gopher over TLS

I agree with the stream hack, it isn't really beautiful.
To the point of Gopher+. It isn't an official RFC standard therefore we shouldn't really care about it IMO.

It was thus said that the Great Sean Conner once stated:

  One way to extend is to include an extra field at the end:

0About	/about.txt	example.org	70	s

I like the solution. The server and clients need modification to support Gopher over TLS. Therefore it is ok to modify the syntax.


Am 15.03.20 um 22:59 schrieb Sean Conner:
It was thus said that the Great Emil Engler once stated:
Hi, I read your blog.
Let's say we register the URI scheme gophers: with port 7000 and all the
other stuff you mentioned.
What if the request contains something like an additional character
(maybe an ASCII control sequence?) like other suggesetd on the ML. If
the gopher client provides this the server uses TLS, if not it'll use
plain gopher.

   There are two issues here---one is with the gophermap file, and the other
with the actual request the client makes.  Let's start with the gophermap.
Normally, a line will look  like:

0About	/about.txt	exammple.com	70

   One way to extend is to include an extra field at the end:

0About	/about.txt	example.org	70	s

   One open question about this method is the interaction with Gopher+.  I'm
not aware of many Gopher+ servers *or* clients, but until it's determined
that Gopher+ is *not* used (or so little used as to be moot) then a way to
integrate this method with Gopher+ is required.

   Another approach, much like with non-gopher links, is to just do:

0About	/about.txt	URL:gophers://example.com/0/about.txt	example.com	70

   This has the benefit of using an existing mechanism. The downside is that
every link on a secure gopher server would need to have such links.  This
means either a map of absolute URLs like the above, or the gopher clients
would need to now understand URLs to support links like:

0About	/about.txt	URL:/about.txt	example.com	70

which means suporting section 5 of RFC-3986 (the URL RFC) to resolve
relative URLs.  Or not, but then a gopher server that supports URL:
selectors [1] would have to handle relative links as well.

   An alternative method, much like URL:, is to use TLS:

0About	/about.txt	TLS:/about.txt	example.com	70

or maybe:

0About	/about.txt	/about.txt	TLS:example.com	70

   Again, a gophermap would have to annotate every TLS link.  Adding TLS: to
the selector means the server might have to support such a selector (per
URL:).  Adding it to the host, which (in my opinion is where it should go)
would break existing clients.

   I don't like the "stream sniffing" hack---checking the initial bytes of
the request to see if it's a TLS handshake or not.  Besides being a hack, it
also complicates the server implementation, especially if one is using a
pre-existing TLS library (which may make such a hack difficult to downright
impossible depending upon the library).

   As I stated in my blog post, adding TLS is the easy part.  The hard part
is integrating it without breaking existing clients.


[1]	I can't locate the document right now, but the URL: proposal also
	mentioned gopher servers to also handle URL: prefixed selectors for
	those gopher clients that can't handle it.  I added such support to
	my own gopher server [2].

[2]	https://github.com/spc476/port70



Reply to: