Currently, the "speculative specification" has the following to say about how Gemini clients should validate TLS certificates when connecting to servers: > Clients can validate TLS connections however they like (including not > at all) but the strongly RECOMMENDED approach is to implement a > lightweight "TOFU" certificate-pinning system which treats self-signed > certificates as first- class citizens. Well, there's a *little* more detail than that, but not much. To the best of my knowledge, all extant clients take the "not at all" route. I'm looking to change this for the case of AV-98 and so wanted to start thinking a little more clearly about what the different possibilities are for making TLS as secure as possible without relying on certificate authorities. Before even starting to talk about this, it makes sense to at least vaguely specify a threat model. I don't think it's realistic to aim at Gemini being resilient against targetted attacks from state-level actors, and given the likely total lack of commercial content on Gemini in the forseeable future I think cybercriminals are not yet a realistic concern. To my mind the most important things to consider are: * ISPs logging all Gemini traffic * ISPs altering Gemini traffic (e.g. to insert adverts) * ISPs terminating connections when blacklisted keywords are seen, to facilitate government-mandated censorship All of these things do happen right now or have happened previously in the context of the web, so they're not ridiculous to consider. None of these things are targetted, in the sense that they are most probably done to *all* traffic on a given set of ports using automated systems, without any special case-by-case consideration. This means that effective countermeasures don't necessarily need to be things that couldn't be defeated by a smart person with a little effort, they just need to be not so trivially defeated that the attack can be easily and reliably automated. Right now, all use of TLS for Gemini *can* be easily and reliably automated because there's nothing to prevent MITM attacks. At the very least, it seems sensible for a client to insist that a certificate's "Not Before" and "Not After" validity dates agree with the current date, and that the hostname the client is trying to connect to is consistent with either the certificate's Common Name or Subject Alternative Names. This only prevents extremely stupid MITM attacks which try to use a generic bogus certificate to attack all connections, but it's relatively straightforward to do and raises the bar slightly, so why not recommend it? Onto more serious attempts at preventing MITM: I've always thought that a TOFU style approach would work well for this, but before digging into this more I'll quickly metion something else I read about today which could be a great tool for Gemini - I don't discuss it before TOFU here because I think it's better than TOFU, I do it because I think it can be described quickly and easily and doesn't raise as many implementation questions. DNS-Based Authentication of Named Entities (DANE, see https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities) basically involves using DNS records to let domain owners declare certain things about which certificates should be considered valid for their hostnames, and one thing a DANE record can declare is that "exactly this verbatim certificate should be used and none other". This means that a successful MITM attack also requires a successful attack on the user's DNS system - which of course is not impossible, but it raises the bar substantially. I think DANE could be part of a good security-in-depth design. Anyway, onto the TOFU. The basic TOFU model involves blindly trusting a certificate the first time you encounter it, but *remembering* that certificate (or rather, just its fingerprint, basically a hash digest) and warning the user if a different certficiate is encountered in the future. In principle this approach means that a MITM attack can only be pulled off the first time a user connects to a particular host. Which, now that I think about it, actually offers much better defence against targetted attacks than the automated dragnet stuff that is supposed to be part of Gemini's threat model - a TOFU client which only ever accesses Geminispace from the same home internet connection through the same ISP is vulnerable to bulk MITM attacks. Hrmh. The TOFU model sounds simple enough but questions appear once you start actually trying to code it. The first one I had was whether or not certificates should be "remembered" against IP addresses or hostnames. This question is pertinent because Gemini's use of URLs instead of selectors as requests enables name-based virtual hosting, so it's possible for one IP address to map to multiple hostnames. It turns out that most TLS implementations (including even the Python standard library's ssl module, which I've started to take a dim view of) support a TLS extension called Server Name Indication (SNI) where the client sends the hostname of the server it think it's connecting to as part of the TLS handshake. This allows virtual hosting servers to serve up distinct certificates for distinct hostnames. This is a good thing because it allows shared hosting where each user can take responsibility for their own certificates. I am thinking of amending the Gemini spec to say that clients SHOULD use SNI. The end result of this is that TOFU clients should store certificate fingerprints against hostnames, not IP addresses. So, there's that question solved and I'll code this up for AV-98 soon. The next question is what to do about certificate expiration. The first time a client connects to a host after that host's previously seen certificate has expired, the client EXPECTS to see something new. If it simply blindly trusts the first new thing which comes along, this basically means that a client is periodically vulnerable to MITMs at certain times - times which are publically announced far in advance! A very simple way to partially mitigate this problem might be to recommend that Gemini certificates be relatively long lived - although this is a trade-off because it means the damage from a compromised certificate lasts longer. A much better solution is some sort of scheme where servers sign their new certificates using the key associated with their old certificate, authenticating the continuity - this is really beautiful, but it would require server admins to use a specialised certificate genreating tool, which feels unlikely to take off. There are various more complicated schemes people have proposed to make TLS work without CAs, like the idea of "public notary" servers. I'm very interested in exploring these possibilities for Gemini. Probably any such system would be a recommendation only for especially security-conscious clients, with vanilla TOFU being the more common baseline. Thoughts very welcome! Cheers, Solderpunk
solderpunk writes: > To the best of my knowledge, all extant clients take the "not at all" > route. Just a quick correction: because elpher uses emacs' own TLS support, it
I want to push back on the idea of TOFU certificates a little bit. Mainly, I feel like I'm missing some important context that led to this decision of rolling your own security model. > Simplicity: > > * It should be possible for somebody who had no part in designing the > protocol to accurately hold the entire protocol spec in their head > after reading a well-written description of it once or twice. > * A basic but usable (not ultra-spartan) client should fit comfortably > within 50 or so lines of code in a modern high-level language. > Certainly not more than 100. > * A client comfortable for daily use which implements every single > protocol feature should be a feasible weekend programming project > for a single developer. Why not just use PKI/TLS and be done with it? It seems like this would be the most obvious and easiest to implement solution for both clients and servers. Setting up Let's Encrypt is about as difficult as setting up a self-signed certificate (correctly). I would wager that most servers running gemini will already be running HTTPS anyway, so it won't even require any extra effort. Your operating system already has the trusted root CAs installed. OpenSSL already knows how to hook everything together. It's one line in python to use PKI/TLS as a gemini client: > context = ssl.create_default_context() You could argue that PKI is overkill for gemini, and to an extent I agree with this on a philosophical level. It just happens to be that the way operating systems and SSL libraries have evolved, you effectively get PKI for "free" from the perspective a software developer. The same way that I don't need/want to know how the TCP handshake works at the kernel level, I would rather let the operating system handle my trust model for me. - Michael
> Just a quick correction: because elpher uses emacs' own TLS support, it > *does* actually validate TLS connections, and warns users when the > server is using a self-signed certificate. I.e. it's a bit pickier than > the speculative specification suggests. I'm looking to "downgrade" this > to a TOFU system somepoint soon, seeing as self-signed certificates are > expected to be the norm. But in any case, MITM attacks should already > be detectable, as far as I understand. Whoops, thanks for the correction! Of *course* emacs has built in TLS support. :p Cheers, Solderpunk
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
On Tue, Sep 24, 2019 at 10:19:45AM -0400, Michael Lazar wrote: > I want to push back on the idea of TOFU certificates a little bit. Mainly, I > feel like I'm missing some important context that led to this decision of > rolling your own security model. Actually, I'm feeling fairly susceptible to this push back. Back in the veeeery early days of Gemini, probably before I'd even resolved to actual take it on as a real project, somebody asked if using TLS meant we were gointg to adopt the CA system, with all of its problems. I said I'd be quite open to exploring some less centralised alternatives like TOFU and they were very enthusiastic about that idea. I think TOFU has just kind of come along for the ride since then without being critically assessed. To some extent, unconventional and creative use of TLS has become a bit of a signature move for Gemini, with the client certificate ideas. You are right that, because the CA approach to certificate validation is so ingrained in the web world, it's actually likely to be much, much easier to correctly implement than TOFU. And while there are valid criticisms of the CA system, at the very least Gemini could claim to be no worse than the web. How do other people feel about this? What proportion of extant Gemini servers are already using Let's Encrypt certs? Cheers, Solderpunk
> 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. Yeah, me too, it's probably why I've continued to fly the TOFU flag for so long. In addition to decentralisation, I do think TOFU is actually
I'm a let's encrypt user on Tilde Black. Being that I have no idea what TOFU is, I'm pretty excited about being able to piggy back on the keys I already have. Does this complicate the possibility of running Gemini over tor (as an onion service, not through an exit node)? SSL certs for onion services are not really a widespread thing, but I'm below novice level in this conversation so I defer to you all.
> How do other people feel about this? > > What proportion of extant Gemini servers are already using Let's Encrypt > certs? > > Cheers, > Solderpunk All in for TOFU and not re-creating what?s already used for the web, the SSH way looks good to me. So far I only use a self-signed certificate but I also have let?s encrypt certificates for the web/mail stuff. I don?t mind not re-using them for Gemini. ? julienxx
solderpunk <solderpunk at SDF.ORG> writes:
> What proportion of extant Gemini servers are already using Let's
> Encrypt certs?
Carcosa isn't, but at this point it trivially could be; the www server
on the same host is.
--
Jason McBrayer | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.?
| ? Robert W. Chambers,The King in Yellow
On 9/24/2019 10:48 AM, solderpunk wrote: > On Tue, Sep 24, 2019 at 10:19:45AM -0400, Michael Lazar wrote: >> I want to push back on the idea of TOFU certificates a little bit. Mainly, I > > You are right that, because the CA approach to certificate validation is > so ingrained in the web world, it's actually likely to be much, much > easier to correctly implement than TOFU. And while there are valid > criticisms of the CA system, at the very least Gemini could claim to be > no worse than the web. > > How do other people feel about this? I'm basically along for the ride here, but would suggest that perhaps more than one model might be specified as an implementation at the option of the developers? Clients would be able to negotiate based on what the servers they encounter supports? I do lean towards the CA system. It's known and devs are familiar with it, where the concept of adoption is concerned. And having Elpher need to downgrade its security model... I dunno. > > What proportion of extant Gemini servers are already using Let's Encrypt > certs? > V'Ger does. -- Bradley D. Thornton Manager Network Services http://NorthTech.US TEL: +1.310.421.8268
On 9/24/2019 4:58 PM, Bradley D. Thornton wrote: > > > On 9/24/2019 10:48 AM, solderpunk wrote: >> >> What proportion of extant Gemini servers are already using Let's Encrypt >> certs? >> > > V'Ger does. > > I should add, that although the future of CAcert is uncertain they are a well funded non-profit, and notwithstanding whether we go the TLS route or some other scheme; when/if there's server support for CA signed client-certs, V'Ger will already recognize CAcert signed client-certs, which are always free for anyone to obtain. -- Bradley D. Thornton Manager Network Services http://NorthTech.US TEL: +1.310.421.8268
Bombadillo (on the `tofu` branch, soon to be merged into `develop`) has implemented a trust on first use system. I am storing hashed certs for comparison and validating hostnames and valid dates/times for all certificates. Servers offering multiple certificates is allowed, but Bombadillo will only store the first valid one it finds. It is working really well so far. Of the active gemini servers the only one I get a bad certificate from is carcosa.net (which, with how I have built things, prevents the site from being visited at all). My takeaway regarding TOFU: - A tofu system was pretty trivial to set up - It seems to work pretty well - It took a bit to figure out how I wanted to handle certificates expiring - It leaves the client to determine how strict they want to be (will they allow a user to still retrieve data even with a bad cert?) I was pretty in favor of this model before and continue to be. Servers can still use Let's Encrypt and present a certificate to the client and the client will validate it in its own way rather than through a certificate authority. In terms of adding overhead to gemini as a weekend project: I had the benefit of already having written a parser for a config will that also stores bookmarks. So that now stores hashes as well and just has a data model for them in my main client struct. For those without that, using a database (SQLite is likely a perfect option for this use case) could be a good call, or saving to a JSON file and parsing it on client load... in either case it doesnt seem like too big a challenge. Anyway, just thought I'd report in after having gotten that working. Now to figure out sending local certificates to servers... I think I will have pretty good feature coverage after that. Lastly, for any interested parties, Bombadillo now has a website and gopherspace (it will have a gemini mirror as well, just as soon as I get jetforce to work for me... I had some issues, but will be working through them): http://bombadillo.colorfield.space gopher://bombadillo.colorfield.space
> My takeaway regarding TOFU: > - A tofu system was pretty trivial to set up > - It seems to work pretty well > - It took a bit to figure out how I wanted to handle certificates expiring > - It leaves the client to determine how strict they want to be (will they allow a user to still retrieve data even with a bad cert?) > Thanks a lot for the feedback! Your devlog entry will help me a lot adding TOFU to Asuka. > Lastly, for any interested parties, Bombadillo now has a website and gopherspace (it will have a gemini mirror as well, just as soon as I get jetforce to work for me... I had some issues, but will be working through them): > http://bombadillo.colorfield.space > gopher://bombadillo.colorfield.space Bombadillo 2 is really cool, great work!
Brian Evans <b__m__e at mailfence.com> writes:
> It is working really well so far. Of the active gemini servers the
> only one I get a bad certificate from is carcosa.net (which, with how
> I have built things, prevents the site from being visited at all).
Hmm. I'll fix the certificate today, by copying over my Let's Encrypt
certificates from the web server. What's wrong with the existing ones,
other than being self-signed?
--
Jason McBrayer | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.?
| ? Robert W. Chambers,The King in Yellow
---