Re: Gopher TLS support in curl
On Mon, Dec 21, 2020 at 09:18:40PM -0800, Cameron Kaiser wrote:
The server would, but not the client. The client receiving some garbage
in the response that isn't a valid Server Hello would error out and
drop the connection.
Agreed, but then the next step on the client side is to retry unencrypted,
because it may be talking to a server that just doesn't support TLS (it
doesn't have a definitive way of knowing that it shouldn't retry the link).
Otherwise how does such a client interact with servers that *don't* support
TLS, assuming it has no prior knowledge of what the server supports?
No, the next step is to show the error to the user. The client would be
considered utterly broken if it retried by itself. It can only do this
if there was no expectation of "security" in the first place and use of
TLS was only tried opportunistically.
As I understand, curl added a new "gophers" scheme which IS a definite
signal that the server supports whatever "gophers" stands for and is
completely different from opportunistic encryption even though the
implementation on the server side could be identical. The client can't
even assume that the same selector would be accepted if the server
provides both "gopher" and "gophers" service.
I purposefully made parallels with HTTP. If the user seeing an error
replaces https:// with http:// on browser's address bar, then PEBKAC.
Of course, the problem remains how to indicate that "gophers" scheme
in the gophermap. (The SMTP route of publishing that bit in the DNS
sounds rather ugly to me.)
Also agreed, which is why the current thought I've had is to listen on 7443,
and the client needs to try that port first (and then cache the result). I'm
open to other "protocol dances" but ultimately there has to be a secure
means of service discovery.
Using a dedicated port would be relatively non-intrusive (although still
ugly) way to achieve it. The server could then support both encrypted
and plain text on the same port to accommodate clients that don't
support the convention; which is exactly why using a dedicated port or
an additional marker like in Gopher+ is more attractive than a dedicated
item type or a URL:gophers: selector. But any client that does support
the convention should under no circumstances retry with plain text.
What you are describing (try this first?) is again an opportunistic
encryption that doesn't need any special signaling beforehand and like
mandatory one can be done either on a dedicated port or in-band without
much difference as to its security properties.
The client that supports TLS but is instructed by the user to fetch a
plain text gopher resource could, and perhaps should, attempt to use TLS
anyway and then fall back to plain text (which was requested in the
first place) when it fails. (Note that it shouldn't even try to check
certificate.)
But When the "gophers" resource is requested either by having such URI
scheme or by whatever other convention that we are still missing, it
should proceed normally checking certificates and everything and *fail*
on errors. There is simply no place for any fallback in this case.
Both cases can look the same from the server side, but have completely
different implications for the client.
-k
Reply to: