💾 Archived View for gemi.dev › gemini-mailing-list › 000787.gmi captured on 2023-11-04 at 13:06:38. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
There's been some questions on the mailing list about what sort of protection a TOFU scheme in certificates offers. I've written about this on my gemlog a couple of times, and several people have told me that the posts are a good introduction to the subject. Therefore I feel confident about posting links here :) The first one is a short and somewhat sloppy introduction to certificate security in general. The second is a more thorough guide to TOFU as a validation scheme. In general, TLS without any validation at all offers no significant protection. However (and this is worth noting) it does protect data in transit from dragnet surveillance. A simple sniff of network traffic will not reveal the paths you visit on a server, or the query strings you send. That's always something. Any sort of validation at all offers more security on top of that. TOFU is not perfect, but it's a lot better than no validation. gemini://warmedal.se/~bjorn/posts/certificate-security.gmi gemini://warmedal.se/~bjorn/posts/your-gemini-browser-and-server-are-probab ly-doing-certificates-wrong.gmi Cheers, ew0k
Hello, > On Mar 5, 2021, at 10:30, Bj?rn W?rmedal <bjorn.warmedal at gmail.com> wrote: > > There's been some questions on the mailing list about what sort of > protection a TOFU scheme in certificates offers. > I've written about > this on my gemlog a couple of times, and several people have told me > that the posts are a good introduction to the subject. Therefore I > feel confident about posting links here :) Thank you for reaching out, and taking the time to verbalize your usage assumptions. Onwards to your specific points: ? PROTECT DATA IN TRANSIT FROM DRAGNET SURVEILLANCE Yes, somewhat ? ignoring larger issues such as deeper network traffic analyzes. But yes, the transmission is somewhat encrypted, at a bare minimum. Courtesy of TLS though, the aptly named Transport Layer Security. Nothing to do with TOFU per se. The expedient of ignoring certificates altogether would achieve the same effect. Also, the mere existence of certificates and usage of TLS may compromise privacy ? for a given value of "privacy". TLS Fingerprint https://tlsfingerprint.io The use of TLS in Censorship Circumvention https://tlsfingerprint.io/static/frolov2019.pdf Clients could leak unwelcome informations. Servers could generate unique certificates for tracking purpose. The possibilities for abuse are endless, as always. ? TOFU IS NOT PERFECT, BUT IT'S A LOT BETTER THAN NO VALIDATION The same assertion is made by the current specification, toward the end of 4.2 Server certificate validation: "This model is by no means perfect, but it is not awful and is vastly superior to just accepting self-signed certificates unconditionally." Saying so doesn't make it so. My personal point of contention is that I do not buy that argument at all: it seems to be more wishful thinking than actual reality. The operative word in "Trust on first use" is /trust/. Where does the trust come from? Quoting Wikipedia: "The single largest strength of any TOFU-style model is that a human being must initially validate every interaction." https://en.wikipedia.org/wiki/Trust_on_first_use#Model_strengths_and_weaknesses How is this meant to happen in Gemini space? How does this happen in your operating model? How do you trust or not a given certificate? Furthermore: "The largest weakness of TOFU that requires manual verification is its inability to scale for large groups or computer networks." How do you scale it, in your operating model? The usage pattern for Gemini is quite different from SSH. How does SSH usage assumptions translates to Gemini? That's the crux of the question. Until we develop a coherent operating model for TOFU in the context of Gemini, this is all hocus-pocus and cargo cult. These are my personal opinions only. I speak for not other bees, but myself :) > gemini://warmedal.se/~bjorn/posts/certificate-security.gmi > > gemini://warmedal.se/~bjorn/posts/your-gemini-browser-and-server-are-prob ably-doing-certificates-wrong.gmi Thanks for sharing though, but this fails short, in my view, of a coherent operational model. YMMV as always. ?0?
> ? PROTECT DATA IN TRANSIT FROM DRAGNET SURVEILLANCE > > Yes, somewhat ? ignoring larger issues such as deeper network traffic analyzes. But yes, the transmission is somewhat encrypted, at a bare minimum. > > Courtesy of TLS though, the aptly named Transport Layer Security. Nothing to do with TOFU per se. > > The expedient of ignoring certificates altogether would achieve the same effect. > > Also, the mere existence of certificates and usage of TLS may compromise privacy ? for a given value of "privacy". > > TLS Fingerprint > https://tlsfingerprint.io > > The use of TLS in Censorship Circumvention > https://tlsfingerprint.io/static/frolov2019.pdf > > Clients could leak unwelcome informations. > Servers could generate unique certificates for tracking purpose. > The possibilities for abuse are endless, as always. Yes. Note that I don't -- for example -- claim that it protects us from meta data or tracking. As you say, there are endless options for abuse. Most of those apply to the CA cert validation scheme too, of course. Any data we send or receive is a data point that can be harvested at some point and form along the way, and the more data points an adversary has the more it can analyse and infer. > ? TOFU IS NOT PERFECT, BUT IT'S A LOT BETTER THAN NO VALIDATION > > The same assertion is made by the current specification, toward the end of 4.2 Server certificate validation: > > "This model is by no means perfect, but it is not awful and is vastly superior to just accepting self-signed certificates unconditionally." > > Saying so doesn't make it so. > > My personal point of contention is that I do not buy that argument at all: it seems to be more wishful thinking than actual reality. > > The operative word in "Trust on first use" is /trust/. > > Where does the trust come from? You are absolutely right. As I wrote in my second gemlog post: "Trust On First Use basically means that if I can't verify the identity of the server I connect to, I can at least make sure to check that it's the same server on any subsequent connections. In and of itself this is not a terrible scheme. As mentioned in the spec no certificate chain needs to be sent, for example. This can almost half the amount of data sent on in a single request, as gemtext documents are typically quite small. We also protect ourselves from Man in the Middle Attacks on all connections except - notably - the first. The downsides are equally obvious. First of all we can't automatically validate the server on our first connection. Neither can we really on subsequent connections; we can only tell if it's still the same host." In a CA scheme we trust the CAs. Despite the CA system having its own set of flaws (did you know that a company Example Inc can be incorporated in two different states in the US by entirely different people, and thus both buy legitimate certificates for the same domains, as the CAs will assume that it's the same corporate entity?). Basically, whichever scheme we choose will have its own flaws and merits. It's very much a matter of which flaws you find to be most dangerous or abhorrent. For my own sake I very much liked both your implementation of the mercury protocol and Solderpunk's speculative post about it. There's something alluringly simple about proclaiming that "F it, TLS is just security theatre anyway!" and skipping it altogether. And it wouldn't be entirely wrong; there are some huge and obvious problems with it, as we've seen. I twitch nervously whenever sending login credentials over an unencrypted connection, though, knowing that it'll be stored in plain text in someone's log somewhere along the way. I definitely think that TOFU solves some problems. Not all, but some. And somewhere we have to decide which problems we want to solve and which ones we're willing to accept. Gemini is not a great protocol if you're in need of strong privacy. Cheers, ew0k
> On Mar 5, 2021, at 11:30, Bj?rn W?rmedal <bjorn.warmedal at gmail.com> wrote: > > I definitely think that TOFU solves some problems. Not all, but some. > And somewhere we have to decide which problems we want to solve and > which ones we're willing to accept. Gemini is not a great protocol if > you're in need of strong privacy. Indeed. Arguably, no protocols are :) It's my opinion that the easiest course of action is to ignore the TOFU problematic altogether ? and blindly use TLS for transmission security only. TOFU doesn't seem to be a good operational fit for Gemini. Developing a whole new trust model to support it is beyond the scope of the Gemini protocol ? in my view. The easiest win would be to stick to just plain TLS ? and call it a day. ?0?
> It's my opinion that the easiest course of action is to ignore the TOFU problematic altogether ? and blindly use TLS for transmission security only. > > TOFU doesn't seem to be a good operational fit for Gemini. > > Developing a whole new trust model to support it is beyond the scope of the Gemini protocol ? in my view. > > The easiest win would be to stick to just plain TLS ? and call it a day. An absolutely valid opinion. Just accept any cert and go. Any client developer out there can already do that, of course (and any automated clients have to, in the current state of affairs). Another option is to stick with CAs, which all(?) TLS libraries do by default. Also a valid opinion. I personally like TOFU, but it's proven to be very very hard to communicate to implementers and server operators what TOFU means for them. Basically, in my opinion, all these three options have merits and flaws and I'd be okay with any of them as the final choice. Cheers, ew0k
> On Mar 5, 2021, at 11:30, Bj?rn W?rmedal <bjorn.warmedal at gmail.com> wrote: > > There's something alluringly simple about proclaiming that "F it, TLS is just > security theatre anyway!" and skipping it altogether. Security theatre! You will find a kindred spirit in Bruce Schneier ? of Applied Cryptography fame. https://www.schneier.com/essays/archives/2009/11/beyond_security_thea.html https://en.wikipedia.org/wiki/Security_theater While the above essay focuses on [ physical | political | societal ] security, the exact same dynamics apply to digital systems. ?0?
---
Previous Thread: [Press] DE: Article about gemini in c't/heise