Re: Gopher TLS support in curl
Cameron Kaiser <spectre-nb4sah8SP49Wk0Htik3J/[email protected]> Tue, 22 Dec 2020 00:25:59 -0800 (PST)
| Newsgroups | gmane.network.gopher.general |
|---|---|
| Message-ID | <[email protected]> |
> 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. Let me stipulate that we're in violent agreement opportunistic encryption isn't going to wash here. But while you will have a gophers:// resource specified initially, a client will lose this information when it gets into a gopher menu that points to another source. Example: you access gophers://secure.invalid/ and you get this menu: 1Is it secure or not unknown.invalid 70 What do we do with unknown.invalid? Should we access it as TLS or not? Does it even support that? If the port were 7443 we could assume it was secure only, but this one just says port 70. cURL doesn't have this problem because it accesses servers with full URLs, but a dedicated client will have to sort this out because right now the Gopher menu doesn't tell it. Or do we specify that gophers:// must be provided in a menu always as a hURL? That's a little icky, but it would be unambiguous, and I can't think of a client that doesn't support hURLs but does support TLS. -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser-nb4sah8SP49Wk0Htik3J/[email protected] -- The point of good writing is knowing when to stop. -- Lucy Montgomery ------