💾 Archived View for gemi.dev › gemini-mailing-list › 000382.gmi captured on 2024-03-21 at 17:29:29. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Hey everybody, For my gemini capsule's tls setup, I just used my Let's Encrypt certificate since I already had it set up for my web site. However, after reading deeper into server setup with gemini, I discovered that I'm probably adding a lot of extra request overhead by using a certificate from a CA instead of self-signed. Now my problem is that if I change out the certificate, then people that have previously visited my site may think it is compromised because the certificate changed and most clients are TOFU. Should I change out the certificate or is it fine to leave it as is? As an additional question, if I was writing a more advanced gemini client, should I validate cert chains if they're availaible or only use TOFU on the fingerprint and ignore chains entirely? The spec just says to validate however you want, but what's the community's recommendation? -- Alex // nytpu alex at nytpu.com GPG Key: https://www.nytpu.com/files/pubkey.asc Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B https://e-mail.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200921/2c28 8e16/attachment.sig>
On 2020-09-21 (Monday) at 19:04, Alex // nytpu <alex at nytpu.com> wrote: > Hey everybody, > > For my gemini capsule's tls setup, I just used my Let's Encrypt > certificate since I already had it set up for my web site. However, > after reading deeper into server setup with gemini, I discovered that > I'm probably adding a lot of extra request overhead by using a > certificate from a CA instead of self-signed. Now my problem is that if > I change out the certificate, then people that have previously visited > my site may think it is compromised because the certificate changed and > most clients are TOFU. Should I change out the certificate or is it fine > to leave it as is? IMHO, you're fine as-is. I think I changed out breadpunk.club's cert when the Let's Encrypt one for HTTPS updated/changed, but I don't think you have to worry about it til then, if even then. There might be more advanced statistics for who has a full cert vs. self-signed around somewhere, though. > > As an additional question, if I was writing a more advanced gemini > client, should I validate cert chains if they're availaible or only use > TOFU on the fingerprint and ignore chains entirely? The spec just says > to validate however you want, but what's the community's recommendation? Again, IMHO, but I'd just do TOFU validation on the fingerprint ... unless you want to maybe be the *most* advanced gemini client out there! -- ~ acdw acdw.net | breadpunk.club/~breadw
On Mon Sep 21, 2020 at 3:04 PM EDT, Alex // nytpu wrote:
> As an additional question, if I was writing a more advanced gemini
> client, should I validate cert chains if they're availaible or only use
> TOFU on the fingerprint and ignore chains entirely? The spec just says
> to validate however you want, but what's the community's recommendation?
Coincidentally, I just finished a TOFU implementation in my client which
I'm relatively satisfied with. To answer your question directly, I chose
to disregard the certificate chain and *always* use TOFU. I don't think
the CA cabal is something Gemini needs to get used to supporting.
In more detail, the TOFU algorithm I decided to use is:
1. On startup, the client loads a list of known hosts from
~/.local/share/gmni/known_hosts (adjusted per XDG basedirs as
appropriate), which is a plaintext file where each line is one host,
with the following attributes in order, separated by spaces:
hostname fingerprint-algorithm fingerprint expires
fingerprint-algorithm is always "SHA-512"; if it's not, this
known_hosts entry is discarded. The fingerprint is the SHA-512 digest
of the X509 certificate, and expiry is the Unix timestamp of the
certificate's notAfter time.
2. Upon receiving a request to validate a certificate:
A. It confirms that the current time is within [notBefore, notAfter].
If not, the trust state is INVALID, GOTO 3.
B. Computes the fingerprint.
C. Consults the list of known hosts for a matching host. If not
found, the trust state is UNKNOWN, GOTO 3.
D. If a matching host is found, and the fingerprint matches, the
trust state is TRUSTED. GOTO 3.
E. If a matching host is found, and the fingerprint does not match,
the trust state is UNTRUSTED. GOTO 3.
3. If the trust state is TRUSTED, proceed with the request.
4. If the trust state is UNKNOWN, display the fingerprint to the user
and ask them if they want to trust this certificate, now or always.
If always, another entry is written to known_hosts.
5. If the trust state is INVALID, the user is told about the issue and
given the option to continue (but not to update known_hosts).
6. If the trust state is UNTRUSTED, the user is told so and the request
is aborted. The user must manually intervene in the known_hosts file
to continue.
Code is here:
https://git.sr.ht/~sircmpwn/gmni/commit/02f6af661513683f0c6c1465c5ff1dd8f03a30c9
> For my gemini capsule's tls setup, I just used my Let's Encrypt > certificate since I already had it set up for my web site. However, > after reading deeper into server setup with gemini, I discovered that > I'm probably adding a lot of extra request overhead by using a > certificate from a CA instead of self-signed. Now my problem is that if > I change out the certificate, then people that have previously visited > my site may think it is compromised because the certificate changed and > most clients are TOFU. Should I change out the certificate or is it fine > to leave it as is? I had the same problem for my capsule, gemini://makeworld.gq. What I did was wait until the Let's Encrypt cert expired for a clean transition, and then created my own small 5-year cert. See my gemlog post for details on how to generate these: gemini://makeworld.gq/gemlog/2020-07-06-openssl.gmi There is also the gemcert tool: https://tildegit.org/solderpunk/gemcert > As an additional question, if I was writing a more advanced gemini > client, should I validate cert chains if they're availaible or only use > TOFU on the fingerprint and ignore chains entirely? The spec just says > to validate however you want, but what's the community's recommendation? Only validate the certificate in the chain that applies to the host you're visiting, ignore all the others. Most servers do not send chains anyway, as it adds needless extra bytes. But that does not mean fingerprints shouldn't be used, you can still take the fingerprint of the last cert in the chain. Cheers, makeworld
I think server software should handle certificates for you and clients should TOFU them. Dealing with certificates is annoying and dumb and the CAs are a cabal and we don't need any of that noise in our brave new gemini future. My server implementation generates 1-year certificates on startup for any domain its configured to service, and automatically rotates them. The admin isn't involved in this in any capacity, except to copy+paste the certificate store if they move between servers.
---
Previous Thread: Announcing gmni, a line-mode gemini browser and curl-esque utility program