💾 Archived View for rawtext.club › ~sloum › geminilist › 006081.gmi captured on 2024-03-21 at 16:33:53. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Thomas Frohwein tfrohwein at fastmail.com
Sun Mar 14 03:30:19 GMT 2021
- - - - - - - - - - - - - - - - - - -
On Sat, Mar 13, 2021 at 09:03:30PM +0100, PJ vM wrote:
Over at Gitlab, people are discussing [1] a potential deprecation of
status code 11 (sensitive input). A few points.
Firstly, for certain (possibly many) use cases password authentication
(combined with shorter- or longer-lived "session" client certificates)
is the right choice over only using client certificates. Some examples I
could quickly think of:
* a Gemini interface to a service for which the user already has login
credentials (and other cases where one needs to confirm the user is the
same as an identity previously established by other means than a
certificate)
* any use case for which client certs are simply not portable enough
* the equivalent of "changing one's password" seems (not certain about
this) quite tedious to do in a world with only client certs, for use
cases where the users are pseudonymous
Agree, especially that it's easier memorize an even complex password thana client cert if you use different machines.
It seems clear to me that login credentials and certs are sufficiently
different in practical aspects that certs cannot replace password
authentication for all use cases.
So, and this is really my key point: whether one likes it or not, I
think password authentication will keep being used as long as there is a
way to give input to the server.
Secondly, let's look at why exactly it is considered a bad idea to put
sensitive information in a URL. The reasons given by RFC 3986 §7.5
(quoted at the Gitlab issue) are:
URIs are frequently displayed by browsers, stored in clear text
bookmarks, and logged by user agent history and intermediary
applications (proxies)
The last problem can be avoided by not using relay-type proxies (by
which I mean proxies where the TLS connection is with the proxy rather
than with the destination). Note that all the other problems can be
addressed by client software IF it's possible to distinguish between
sensitive and non-sensitive input. When the server sends 11, the client
can hide the input the user is typing, and throw away the query after
sending the request, before displaying the URL in the URL bar or saving
it in the browsing history.
Agree. Gemini universe can come up with smart enough clients without a lotof technical complexity.
So actually, if we reason from the assumption that password
authentication will happen anyway (as I've argued above), removing
status code 11 has rather negative consequences, as it removes the
ability to distinguish between sensitive and non-sensitive input.
Agree.
My conclusion is that removing status code 11 would be unwise, and
instead it would be better to include a recommendation in the best
practices document to throw away the query part after sending a request
that results from user input on a 11 page. Maybe there should also be a
recommendation to store client certs in a password-encrypted vault, as
of course storing long-lived certs unencrypted is about as much of a
problem as storing sensitive queries in the browsing history.
Thirdly and lastly, about Gitlab. I strongly dislike the fact that
discussions which can have quite an impact on all Gemini users are
happening in Gitlab issues; to stay up-to-date on all these requires
regularly going through multiple webpages, and to comment requires a
Gitlab account! I think this is a mistake.
Agree, even with this one.
Please excuse the length of this email.
[1] https://gitlab.com/gemini-specification/protocol/-/issues/17
--
pjvm
I agree pretty much entirely with pjvm's points.