💾 Archived View for rawtext.club › ~sloum › geminilist › 001250.gmi captured on 2020-09-24 at 02:00:36. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Peter Vernigorov pitr.vern at gmail.com
Tue Jun 2 20:44:08 BST 2020
- - - - - - - - - - - - - - - - - - -
Thanks. These responses and re-reading the spec clarified my initialconcern. Spec clearly states that transient certificates should not beshared across domains. And there is no point using permanent certificatesacross domains as it is assumed that these certificates have a specialmeaning for specific domains.
I am still unclear as to what happens after a transient certificate hasbeen created. Should browser automatically use it for the page thatrequested it and any other pages on that domain? I don’t see a goodsolution here. Either certificate is sent only when server requests it,which would double number of requests (assuming user stays in privatesection of the site), or certificate is always sent, which adds overhead toall requests. Should browser remember which pages need a certificate andalways use it for them?
And additionally, should browser ask user for every page that requires acertificate if existing one can be used?
Thanks for replying to my earlier questions. I want to make sure that mysupport for certificates doesn’t violate the spec or creates a bad userexperience.
On Tue, Jun 2, 2020 at 20:31 solderpunk <solderpunk at sdf.org> wrote:
On Tue, Jun 02, 2020 at 01:31:09AM +0200, Peter Vernigorov wrote:
Question about client certificates: not sure how other clients implement
this, but I was thinking of generating and using the same client cert for
all sites, and giving an option to create a cert for specific domain.
Does
that make sense? Potential problem I see is that main certificate is
something user could be identified by across websites.
It's not super clear to me what you're suggesting.
If it's that the client generates a single self-signed client cert the
first time it starts up and then just sends that cert to every single
host as part of every single request: PLEASE DON'T DO THAT! This is
about as wrong an implementation of Gemini's idea of client certificates
as possible. The vast majority of URLs will not require or expect a
client cert (which is why there's a way for servers to explicitly
request one in the unusual circumstance it's needed), and any you send
will just be ignored. You will be needlessly increasing the TLS overhead
(which is already pretty heavy relative to typical text/gemini payload
sizes) for no gain. Worse, admins of unrelated servers would be able to
compare their logs and track you across Geminispace.
If it's that you generate a single certificate the first time it starts
up but only send it out in response to a status code of 62 that's a
different matter (I assume it goes without saying you shouldn't ever use
it in response to a status code of 61 because the behaviour for
transient certs is extremely clearly specced and this would fly in the
face of just about every part of it). I still think it's the wrong
thing to do, but it's slightly less disasterous than the first option.
Client certificates should be handled in a very deliberate manner - the
user needs make the clear decision to opt in, on their own terms, to
being identified to some server(s). It's an exceptional condition and
should never be automated or hidden from the user for the sake of
convenience. Sharing a single certificate across domains isn't
something anybody should ever do lightly.
Cheers,
Solderpunk
-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200602/597d8546/attachment.htm>