💾 Archived View for rawtext.club › ~sloum › geminilist › 006632.gmi captured on 2023-11-14 at 09:13:11. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
nervuri nervuri at disroot.org
Sun Jun 6 21:20:41 BST 2021
- - - - - - - - - - - - - - - - - - -
On Sun, 2021-06-06, Omar Polo wrote:
nervuri <nervuri at 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'llexpand 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 localtrust store and the downloaded one, local entries from capsules that theuser has visited should take precedence (unless they are expired,perhaps). An option can be provided for advanced users to be notifiedabout such mismatches.
2. Most people don't know what an X.509 certificate is. Rather thanpresenting them with a cryptic SSH-like prompt on every mismatch,clients could do automatic out-of-band verification based on networkperspective. If Tor is available on the user's system, suchverification is simple and anonymous (I exemplified in a previousemail). If Tor is not available, we need a few servers running a CGIprogram that takes a hostname[:port] as input, connects to it andoutputs the certificate it received. Clients could then validate certsby querying these servers. We also need proxies to protect the user'sprivacy when connecting to such servers (one extra hop should suffice -see Anonymized DNSCrypt [1] or Oblivious DoH [2]). You can look atTrust Seeker [3] for some ideas, although it's just an early sketch andthe code is embarrassing at this point. This month I hope to reboot theproject.
3. Client authors don't have to bundle *all* certificates. They maypick only a few Gemini hubs with certificates set to expire many yearsinto the future. This can be done manually. Alternatively, they mayonly want to exclude short-lived certs, like those signed by Let'sEncrypt. The trust store generator scripts allow for this. Forinstance, 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