💾 Archived View for rawtext.club › ~sloum › geminilist › 002107.gmi captured on 2020-11-07 at 02:40:59. Gemini links have been rewritten to link to archived content

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

Removing expiry dates for TOFU

Baschdel baschdel at disroot.org

Tue Jul 7 18:06:07 BST 2020

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

I really like the way of announcing future certificates by putting them in a well known location (not just their fingerprint, as this requires either the server or the client (probably both) to support multiple fingerprinting algorithms because even if we agree on one hash algorithm today, there are already people trying to break it and updating that will be a mess).

That said the name of this well known location should include the name tls somewhere to keep the door open for potential tls replacements (I think TLS is a great choice, but if something else emerges I don't want to bother with legacy magic paths).

There are also three other certificates besides the future one that could/should be served at a well known location:

- Alternative (Backup) certificates for both the current and future certificate, that can be used when the key behind the original certificate was compromised, they have to be valid for the same time-span as the originals and become the originals as soon as they are used. The private keys of these of course should be kept in cold storage until they are needed. Clients should at least notify the user when they see a backup certificate being used and treat the original certificate as untrusted but not delete it immanently (as it is possible that only the backup key was compromised and still be used by the original server). The user must have the ultimate choice which certificate to trust after a backup certificate has been used as which certificate is trustable should be communicated out of band in such a case.

- The currently used certificate that could be checked by clients to detect general purpose dragnet TLS interception, that knows nothing about Gemini and its conventions (basically what I'd do if I was the dictator of a surveillance state to monitor and censor internet access for thousands or millions of people). This too could also be useful if some TLS alternative emerges, you already trust one key the server uses, so why not use that to get the other keys it uses. Another possible usecase is that someone really concerned could use any niche proxy protocol to fetch the certificate the server should have (I know portal.mozz.us already has a feature that allows one to fetch the server certificate but proxy.vulpes.one doesn't and a gemini to gemini proxy would have to use a well known endpoint to fetch the certificate anyway (but that wouldn't allow you to check if the proxy got MitMd by a lazy TLS interception)) To make this even more of a pain for attackers each server could have (a) secondary endpoint(s) that is/are only communicated in human readable form (i.e. generating a captcha image that contains the filename in a nonstandard location) that changes on a regular basis) that too serve(s) the certificate used with the possibility for a security focused client to have a tool that can automatically check against the certificates it trusts and the one it received from the server. (All of this can be realized by adding two configuration options to a Gemini server, or if the server doesn't support that symlinks should work as well).

Again, I'm just throwing Ideas around hoping that they'll be considered useful.

Have a nice Evening

- Baschdel

-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200707/f3df19bb/attachment-0001.htm>