TLS, TOFU and the Gemini security model

[Brian Evans]

Thanks for the detailed thoughts solderpunk. I do not know almost anything about TLS.
The TLS portion of this was the hardest for me to get going in my client, even while
implementing the "not at all" approach. There is a lot to know and understand on the
subject and it can be overwhelming to look into. Which, as Michael points out, does
go somewhat against the mandate of ease of setup/build. Python may have a robust
library for this, but not every language does (golang has a solid library for it, or so it
seems... but it is hard to understand if you do not already know what you are doing.
Most of the easy routes are designed explicitly for https and will not work with other
protocols).

Michael writes:
> Setting up Let's Encrypt is about as difficult as setting up a self-signed
> certificate (correctly)

I agree that Let's Encrypt is easy to set up and I have done so for multiple websites.
However, I think from a philosophical standpoint I, personally, would like gemini to
be as free of centralized authorities as is possible. 

As such, the TOFU approach sounds.... doable mostly. It makes sense to me how to
get a hash of a cert and then store that in a map with a hostname as the key. My client
already stores and parses a config file with options and bookmarks, so adding cert
hashes seems like no problem. The timeout portion worries me a little bit. I agree that
long timeouts makes sense, but that trade off is something to think about.

solderpunk writes:
> [ ... ] and that the hostname the client is trying to connect to
> is consistent with either the certificate's Common Name or Subject
> Alternative Names

I had been planning on implementing this from the beginning and only threw it aside
in order to be able to just get connections up and running at all. I think I'll spend some
of today trying to get it set up. :)


--?
Sent with https://mailfence.com
Secure and private email