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