💾 Archived View for rawtext.club › ~sloum › geminilist › 006623.gmi captured on 2024-03-21 at 16:21:47. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

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

nervuri nervuri at disroot.org

Sat Jun 5 22:48:24 BST 2021

- - - - - - - - - - - - - - - - - - -

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 beenoffline for a while (2-3 weeks). Aside from this, there's a link to mycontact info in the project's README, if a domain admin wants to requestremoval.

I don't see why anyone would, though. The repo does not hold capsulecontents or personally identifiable information. It just containscopies of public TLS certificates, which can help people connect moresecurely.

- 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 areavailable 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)", asstated 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 approachin 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 doingit because TOFU does not protect the first connection. Also, the intenthere is not for this repo to be a single source of trust. I'd likeother people to run these (or similar) scripts and publish certificatesdownloaded from their network perspectives. Having verification frommultiple sources will give us a more trustworthy ecosystem.

I also want to encourage client authors to bunlde pre-generated truststores (verified from several perspectives) into their clients, toprotect the first connection. However, this by itself is not enough; wealso need an out-of-band verification method to help with certificatemismatch prompts. These prompts arguably do more harm than good if theyare frequent and users have no information on which to base the trustdecision. 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 andOpenSSL. 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 arandom Tor exit node. You can run it repeatedly to check from multipleTor perspectives. To get the fingerprint in your client's format, youcan append a few conversion commands. For instance, this gives you thefingerprint 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, tobe executed automatically in case of mismatch on systems where Tor isinstalled.