[tech] Pre-generated trust stores for various Gemini clients

[nervuri]

On Sun, 2021-06-06, Omar Polo wrote:
>
> nervuri <nervuri@disroot.org> writes:
>
>> I also want to encourage client authors to bunlde pre-generated trust
>> stores (verified from several perspectives) into their clients, to
>> protect the first connection.  [...]
>
> from a packager point of view I fear this can break badly.
>
> On OSes that provides stable channels, the packages aren't update
> frequently.  If you add to the mix that there are people using Let's
> Encrypt (or similar) and thus change the certificate frequently, there's
> a problem.
>
> There is also another drawback to this, that it ties client authors to
> frequent and periodic updates.  Take elpher for example, it hasn't seen
> commits in a while now (since 2020-09-19 -- almost 9 months!), but it's
> fine because the code still works.

I have mentioned a few solutions to this problem in this thread.  I'll
expand on them here.

1. Clients can periodically refresh the trust store from a chosen source
(that the user can change, of course).  On mismatches between the local
trust store and the downloaded one, local entries from capsules that the
user has visited should take precedence (unless they are expired,
perhaps).  An option can be provided for advanced users to be notified
about such mismatches.

2. Most people don't know what an X.509 certificate is.  Rather than
presenting them with a cryptic SSH-like prompt on every mismatch,
clients could do automatic out-of-band verification based on network
perspective.  If Tor is available on the user's system, such
verification is simple and anonymous (I exemplified in a previous
email).  If Tor is not available, we need a few servers running a CGI
program that takes a hostname[:port] as input, connects to it and
outputs the certificate it received.  Clients could then validate certs
by querying these servers.  We also need proxies to protect the user's
privacy when connecting to such servers (one extra hop should suffice -
see Anonymized DNSCrypt [1] or Oblivious DoH [2]).  You can look at
Trust Seeker [3] for some ideas, although it's just an early sketch and
the code is embarrassing at this point.  This month I hope to reboot the
project.

3. Client authors don't have to bundle *all* certificates.  They may
pick only a few Gemini hubs with certificates set to expire many years
into the future.  This can be done manually.  Alternatively, they may
only want to exclude short-lived certs, like those signed by Let's
Encrypt.  The trust store generator scripts allow for this.  For
instance, you can run:

./generate-trust-store.sh 30- 90+

This excludes certificates for which:

{30 days ago} < cert_expiry < {90 days from now}

So this excludes current Let's Encrypt certs, for instance.  Of course,
the numbers can be much higher - it's up to the developer.

[1] https://github.com/DNSCrypt/dnscrypt-protocol/blob/master/ANONYMIZED-DNSCRYPT.txt
[2] https://datatracker.ietf.org/doc/html/draft-pauly-dprive-oblivious-doh-06
[3] https://tildegit.org/nervuri/trust-seeker