💾 Archived View for gemini.kaction.cc › log › 2023-08-20.1.gmi captured on 2024-08-18 at 17:22:58. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-02-05)
-=-=-=-=-=-=-
https://daniel.haxx.se/blog/2023/05/28/the-gemini-protocol-seen-by-this-http-client-person/
https://xn--gckvb8fzb.com/gemini-is-solutionism-at-its-worst/
People criticize Gemini for standardizing trust-of-first-use policy of TLS certificate verification (FAQ:4.5.5), discussing security and scaling. Here is my take on these issues.
Disclaimer: I have no formal training in cryptography.
Whenever you connect to a server you never connected before and have no a-priory reason to trust, it doesn't really matter whether it has a self-signed certificate or a certificate signed by CA. Well, there is a little difference -- you will know if your DNS response was spoofed in case of CA-signed certificate. But you still has no reason to trust the content server sends to you.
Now suppose this server happens to publish source code of some useful program. You download the source, audit it diligently and deem non-malicious and useful. Server publishes new version of the software, and another one, and you eventually develop trust into the server and its certificate.
Provided that owner of the server protects his private key well, TOFU approach actually reduces attack surface, since there is no CA to enable MITM attack. Sure, the server owner can decide to cash out your trust at any moment, but there is no remedy to it.
Now suppose your friend tells you about a server that publishes a software your friend deems trustworthy. In CA scenario, the domain name of the server would be enough. In TOFU scenario, your friend would also have to provide your with the hash of the server certificate.
For example, for "www.bankofamerica.com" that would be:
$ gnutls-cli www.bankofamerica.com [...] sha256:e93bec53ab72ffaa8ba89bcfb9f5135938851dc4d331261ce3be1448dda1497f [...]
People can't verify sha256 using eyeballs, so it will have to be embedded into the url. Not hard when we can transfer text, e.g message apps or QR code on business cards, quite a challenge when transferring over the phone.
In case of trust by proxy, CA scenario is easier. And unfortunately, we trust by proxy much more often than we develop trust from the scratch. I know domain name of my bank because it is written on the business card I received in a branch. Certificate Authoritices are still an extra attack vector, but they improve usability so much that it is no miracle that humanity chose convenience over security.
The trust-on-first-use verification policy is more cumbersome for common situation of trust by proxy, and that makes it unsuitable for the general public. Good riddance.
Personally, I do not trust any Gemini server or author. I read other people's gemlogs, evaluate their arguments and opinions, take inspiration to dig deeper into some technology, but the human being behind the words is irrelevant to me.
I realize that unless I use Tor, gemini server knows my IP address and what pages I am reading, but I would like to prevent my ISP from knowing it or injecting advertisements. Trust-on-first-use policy does it just fine.
That said, I would definitely appreciate an easy way to share certificate fingerprints database between Lagrange and diohsc on the desktop and Buran on the android phone.