💾 Archived View for thrig.me › blog › 2023 › 06 › 29 › ymgtr.gmi captured on 2023-07-10 at 13:42:28. Gemini links have been rewritten to link to archived content

View Raw

More Information

➡️ Next capture (2023-12-28)

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

yet more TOFU ruminations

In SSH only the fingerprint (of a key type) is available when a host key changes; Gemini instead offers a whole X.509 certificate, for better or worse. The worse involves the complexity of X.509, even the limited modern version, and the too many security vulnerabilities thereof. The better is the metadata, which could be logged, or one might store the whole certificate so that future comparisons can look at whatever fields they want (subject, issuer, etc). Oh no, the disk space usage of unscalable certificate stores!

    $ df -h /home
    Filesystem     Size    Used   Avail Capacity  Mounted on
    /dev/sd0l      295G   64.5G    216G    23%    /home

These years I'm mostly wondering how I might productively use all the disk space and memory. Luckily I don't compile modern chortleware; 8G of memory is six or more like seven too much. Tiny ARM or RISC-V systems might be a better option, though last I looked lilypond ran pretty darn slow on what was probably an original rpi, back from when they shipped it with SSH wide open and a default password set.

The IP address of the gemini server may also be important; if a certificate changes and there's a new IP address along with a bunch of other things, that might be suspicious. This however would run afoul a capsule that runs on a cluster of systems where the IP address will change randomly by default, or there might be a IPv4/IPv6 switcharoo depending on what DNS and getnameinfo(3) coughed up this time.

    $ for t in A AAAA; do host -t $t thrig.me; done
    thrig.me has address 104.207.156.138
    thrig.me has IPv6 address 2001:19f0:8001:143b:5400:4ff:fe1a:8ed6

validns may also be handy if you have a zone file in hand. AnD ALsO DNS 0x20 is A ThINg, i mEAn WHO cOmeS UP wITh tHiS StuFF? HuMaNs!

A not incompetent attacker could ape the various fields of a certificate, especially in a self-signed certificate. Attackers could also generate a Let's Encrypt or some other valid Certificate Authority signed certificate using a hostname that looks similar enough. Hopefully you are not up against a clever attacker who has the necessary influence with a CA to sign whatever they want or one that can do internet routing or DNS tricks. In that case you may have other problems.

I often SSH by IP address by way of the ~/.ssh/config file; usually there is a bastion host or two. If DNS breaks it would be me fixing it, and if you need DNS up to get to your DNS servers…

xkcd://705

    Host somehost.example.org somehost
      Hostname 192.0.2.42

It may be interesting to maintain a database of gemini certificates over time on multiple hosts, and to compare those certificates now and then. Shenanigans may be more apparent if host X sees a different certificate for server E than host Y does at time T. Probably this would mostly track boring certificate rotations and consume a bunch of electricity. And it has been done:

https://tildegit.org/nervuri/trust-stores

Ordinary users could be baffled by extra certificate details in a client; amfora does a pretty good job of indicating the nature of a certificate rotation without too much detail? It might be nice to have more information available somewhere, like maybe via an advanced button. However, adding an advanced button might confuse the heck out of some users, and amfora does not store anything besides a certificate fingerprint and the notAfter date so there's no subject or issuer or IP address details to consider with the rotation.

Privacy might demand that the certificates and hostnames be hashed, like SSH offers for the known hosts file. An encrypted disk would be a good start, though defense in depth could help. The urgency of this will depend on the political climate and whether any local agencies would (or will) be interested in finding other people to chat to based on what they find on your system. Hashed hosts however may not help if your ISP has been saving and selling connection information for your IP and the powers that be can purchase or steal said information. Also there are not too many gemini servers; it would not be difficult to hash all the known hosts according to the hash used by the gemini client and compare that list against what's in the TOFU store.

For SSH I do not hash the known hosts, mostly on account of the ~/.ssh/config file that has all the important hosts listed in it, a lack of local agencies who would be rooting through my computer looking for such things, and a suspicion that the ISP is likely saving connection and DNS information to sell. This equation would likely come out differently in different countries.

If there is a site you do not want folks knowing that you are going to, remove it from any local TOFU stores, connect by IP address to avoid DNS queries being made, and try to make the connection in a way that is less traceable to the computer you are using (wireguard over to host X and then Y and then have a scheduled task that…). Not very convenient, eh?

tags #gemini #tofu

bphflog links

bphflog index

next: errno