[ANN] Gemini browser for iOS

[Peter Vernigorov]

I’ve added support for client certificates in the latest build, basing
mostly on implementation of AV-98. There’s a weird bug when using
gemini://astrobotany.mozz.us/ which requires restart of client for
certificate to work (and for it be deactivated) but
gemini://gemini.conman.org/private/ works properly. Are there any other
servers requiring client certificates that I can test against?

I also updated code to comply with updates to Gemini protocol. Looking
forward to seeing status code 11 in the wild :)

On Tue, Jun 2, 2020 at 21:44 Peter Vernigorov <pitr.vern at gmail.com> wrote:

> Thanks. These responses and re-reading the spec clarified my initial
> concern. Spec clearly states that transient certificates should not be
> shared across domains. And there is no point using permanent certificates
> across domains as it is assumed that these certificates have a special
> meaning for specific domains.
>
> I am still unclear as to what happens after a transient certificate has
> been created. Should browser automatically use it for the page that
> requested it and any other pages on that domain? I don’t see a good
> solution here. Either certificate is sent only when server requests it,
> which would double number of requests (assuming user stays in private
> section of the site), or certificate is always sent, which adds overhead to
> all requests. Should browser remember which pages need a certificate and
> always use it for them?
>
> And additionally, should browser ask user for every page that requires a
> certificate if existing one can be used?
>
> Thanks for replying to my earlier questions. I want to make sure that my
> support for certificates doesn’t violate the spec or creates a bad user
> experience.
>
> 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/20200608/e76c5928/attachment-0001.htm>