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

[nervuri]

On Fri, 2021-06-04, panda-roux wrote:
> - What's your process for requesting the removal of a domain's
> certificate from this list?

I'll be adding code to prune certificates of capsules that have been
offline for a while (2-3 weeks).  Aside from this, there's a link to my
contact info in the project's README, if a domain admin wants to request
removal.

I don't see why anyone would, though. The repo does not hold capsule
contents or personally identifiable information.  It just contains
copies of public TLS certificates, which can help people connect more
securely.

> - Does the software you're using to generate this list respond to any
> robots.txt directives (i.e. "don't index me" or "expire after x days")?

No, because the `get-certs.sh` script is not a crawler and does not
"speak" Gemini.  It only works on the TLS level.  All scripts are
available here [1], by the way.

[1] https://tildegit.org/nervuri/trust-store-generators

> - Does this break if I arbitrarily decide to change my a cert on my
> domain, or is it regularly kept up-to-date?  If so, how often?

Certificates are "updated every few days (no more than a week)", as
stated in the README.  I generally run the scripts once every 3-4 days.
Later I might use a daily cron job, but I want a more hands-on approach
in the initial stage.

> - Why circumvent TOFU?  I don't mean for this to come across as
> antagonistic, but doesn't this defeat the purpose of having a
> decentralized protocol in the first place?

I think "complement" is more appropriate than "circumvent".  I'm doing
it because TOFU does not protect the first connection.  Also, the intent
here is not for this repo to be a single source of trust.  I'd like
other people to run these (or similar) scripts and publish certificates
downloaded from their network perspectives.  Having verification from
multiple sources will give us a more trustworthy ecosystem.

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.  However, this by itself is not enough; we
also need an out-of-band verification method to help with certificate
mismatch prompts.  These prompts arguably do more harm than good if they
are frequent and users have no information on which to base the trust
decision.  People may become accustomed to saying "yes" all the time,
despite the warning.

Here's an example of anonymous out-of-band verification using Tor and
OpenSSL.  In case of mismatch, run:

host_and_port='rawtext.club:1965'
torsocks --isolate openssl s_client -connect "$host_and_port" </dev/null 2>/dev/null \
 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'

This gives you the certificate in PEM format, from the perspective of a
random Tor exit node.  You can run it repeatedly to check from multiple
Tor perspectives.  To get the fingerprint in your client's format, you
can append a few conversion commands.  For instance, this gives you the
fingerprint in Agunua's format (spki:sha256:base64):

host_and_port='rawtext.club:1965'
torsocks --isolate openssl s_client -connect "$host_and_port" </dev/null 2>/dev/null \
 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' \
 | openssl x509 -pubkey -noout \
 | openssl pkey -pubin -outform der \
 | openssl dgst -sha256 -binary \
 | openssl enc -base64 -A

This is cumbersome to do by hand, but it can be built into clients, to
be executed automatically in case of mismatch on systems where Tor is
installed.