Re: Gopher over TLS
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.
-spc
[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
Specifically:
https://github.com/spc476/port70/blob/master/port70/handlers/url.lua
Reply to: