💾 Archived View for gemi.dev › gemini-mailing-list › 000276.gmi captured on 2024-06-16 at 12:50:49. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Hello all, Mozz proposed an interesting idea to me on Github, which was removing expiry dates from TOFU entirely. I wrote a quick post on it, I'd appreciate it if you could read it and offer your thoughts. I think this could help make things more secure on Gemini, and possibly make TOFU and cert management more painless. gemini://makeworld.gq/gemlog/2020-07-05-tofu-2.gmi Thanks, makeworld
Using the same keypair for a very long time is generally considered a bad idea, as it increases both the risk of key compromise and the duration for which a stolen key can be exploited. There's also the issue of ownership of domain names changing over long timespans, and former legitimate domain owners being able to impersonate new legitimate domain owners with old certificates. Even CA certificates have expiry dates. I don't think we should be advising people to use certs which last forever. That said, for typical Gemini applications I don't think something like a three year key/cert lifespan is necessarily a big problem, and would certainly make TOFU issues less common. In principle it doesn't make much sense to rotate your TLS keys much more often than your server's SSH keys, and let's be honest: how often do most of us do that? One idea I had, which could be neat for people who are really serious about good, long-term identity management without CAs, is the following: generate a key pair, for use as an ephemeral signing key, and a self-signed certificate for the public key with 100 years of validity. Then generate 100 additional keypairs, and use the signing key to sign certificates for them with a validity of, say, 1 year each, and consecutive validity periods. Permanently delete the signing key, but keep the self-signed certificate. Move all the 1 year keys to a USB stick, and transfer them one at a time, as they become valid, to your server. For the next 100 years, serve up a two certificate long chain, with the self-signed cert for the signing key, plus your currently active 1 year cert signed with the signing key. Once a client TOFU-accepts the signing key's certificate, they'll be able to validate all the annual key roll overs as originating from the same party, even if they don't visit your site for 10 years at a time. Someone who breaks into your server can steal this year's key, but not any future keys, because they're on the USB stick, so their ability to impersonate you is strictly time-limited. Nobody can steal the original signing key and make their own certificate which will be accepted by TOFU clients, because it's been deleted. Hijacking this identity basically requires stealing the physical USB key. This sounds like a lot of work, but generating all the keys and certs could be trivially automated. Cheers, Solderpunk On 05.07.2020 18:27, colecmac at protonmail.com wrote: > Hello all, > > Mozz proposed an interesting idea to me on Github, which was removing > expiry dates > from TOFU entirely. > > I wrote a quick post on it, I'd appreciate it if you could read > it and offer your thoughts. I think this could help make things more > secure on > Gemini, and possibly make TOFU and cert management more painless. > > gemini://makeworld.gq/gemlog/2020-07-05-tofu-2.gmi > > Thanks, > makeworld
By the way, I appreciate you writing this up, and also your earlier post on TOFU which you shared here. I've finally started work on my gentle TLS cert introduction, it's at gemini://gemini.circumlunar.space/docs/tls-tutorial.gmi. So far it's just background stuff, but TOFU will feature eventually. Keep an eye on it over the next week or so. Feedback welcome at any stage, though. Cheers, Solderpunk
Looks like it was a bad idea after all haha. I wasn't sure about it, so thanks for showing some issues with it. I will have to look at your USB example another time to understand it fully, but it sounds interesting. Another optional security thing like you explained with notaries? > That said, for typical Gemini applications I don't think something like > a three year key/cert lifespan is necessarily a big problem, and would > certainly make TOFU issues less common. In principle it doesn't make > much sense to rotate your TLS keys much more often than your server's > SSH keys, and let's be honest: how often do most of us do that? Maybe this is a better solution, everyone using longer term certs? It still might not be enough though. My thinking behind my original post was that the fewer valid reasons for changing certs the better. If changing certs is very rare, then clients can be more informative to the user, and say with more surety that there is a MITM attack going on. How can we lessen the behaviour of just clicking through any TOFU pop-up? Thanks, makeworld
On Sun Jul 5, 2020 at 8:48 PM CEST, wrote: > Looks like it was a bad idea after all haha. I wasn't sure about it, > so thanks for showing some issues with it. > > Maybe this is a better solution, everyone using longer term certs? It > still might not be enough though. > > My thinking behind my original post was that the fewer valid reasons for > changing certs the better. If changing certs is very rare, then clients > can be more informative to the user, and say with more surety that there > is a MITM attack going on. How can we lessen the behaviour of just > clicking through any TOFU pop-up? Well, I think your overall thinking was very much in the right direction, you just took it too far. :) It's basically just a trade-off. If certificates never, ever expire then TOFU is very simple and clients will never have to show scary messages under ordinary circumstances when everything is fine, but the risk of the private key being stolen or broken (keys which are long enough to be safe today will not be decades later) is very high, and if it happens, the consequences last forever. If certificates expire every week, it's very hard to steal or crack a key before the corresponding cert expires, but TOFU is unworkable without some extra complication on top. The best approach is somewhere in the middle. The question is: where? On the web, certificate lifetimes are getting shorter and shorter - but CAs have a strong financial incentive to be risk averse here, because bad publicity around a single, long-lasting erroneously issued cert will damage their reputation and hence business, possibly quite hard. But Gemini server admins using self-signed certs don't have that risk at all. Also, on the web, TLS is often protecting credit card details, or access to email, or other things people have a strong incentive to actively try to steal. A personal Gemini host serving a gemlog is not likely to be the target of serious efforts at compromise, so yet less reason to be super cautious about key rotation. For low-risk applications, a five year certificate might be perfectly reasonable. One could argue that longer lived certs actually help TOFU work, within reason. The longer a cert is in use, the more opportunity you have to observe that cert being served to you from multiple different networks (at home, at work, at the library, at the airport), which helps build up your trust in it: getting MITMed once on a single network might be a plausible risk. Being consistently MITMed every time you visit a host, from multiple locations, for years and years, is almost impossible, so the longer you see the same cert, the more confident you can become that when you blindly accepted the cert the very first time you weren't being attacked. Cheers, Solderpunk
5 year certs sound like a good compromise to me. We can make client messages sufficiently scary, seeing as a five year expiry will make TOFU issue somewhat rare. Will you set that as a default for your cert tool then? Do you agree with my original recommendation that clients should auto-accept any cert once the old one has expired? This seems relevant here. I think it's nice for UX, although I see the obvious security risk. makeworld
On Mon Jul 6, 2020 at 12:18 AM CEST, wrote: > 5 year certs sound like a good compromise to me. We can make client > messages sufficiently scary, seeing as a five year expiry will make > TOFU issue somewhat rare. Will you set that as a default for your > cert tool then? Maybe! ;) I *do* plan to finally start work on that tool this week, by the way. Hopefully by 2025 we'll have agreed on a way to do smooth roll-overs which is widely implemented! If that does happen, and it's easily automated (which I'd very much like it to be), maybe we can start shifting towards less long-lived keys/certs for a extra peace of mind. > Do you agree with my original recommendation that clients should > auto-accept any cert once the old one has expired? This seems relevant > here. I think it's nice for UX, although I see the obvious security > risk. In the absence of any other roll-over mechanism, yeah, this seems like sane behaviour for a TOFU client. Cheers, Solderpunk
On 2020-07-05 15:18, colecmac at protonmail.com wrote: > 5 year certs sound like a good compromise to me. We can make client > messages sufficiently scary, seeing as a five year expiry will make > TOFU issue somewhat rare. Will you set that as a default for your > cert tool then? > > Do you agree with my original recommendation that clients should > auto-accept any cert once the old one has expired? This seems relevant > here. I think it's nice for UX, although I see the obvious security > risk. Also not that soon(-ish) Apple, Google & Mozilla browsers will _only_ accept certificates with a valid lifetime of maximum 1 year effectively making this a "standard". While not necessarily relevant to Gemini directly, it's something to keep in mind.
On Mon Jul 6, 2020 at 4:35 PM CEST, Laurens Vets wrote: > Also not that soon(-ish) Apple, Google & Mozilla browsers will _only_ > accept certificates with a valid lifetime of maximum 1 year effectively > making this a "standard". While not necessarily relevant to Gemini > directly, it's something to keep in mind. Yes, the CA/Browser forum (https://cabforum.org/) is really pushing for shorter certificate lifespans. It makes a good amount of sense if you buy into the whole CA system. I think under a TOFU scheme the structure of incentives and risks is pretty different. At least in these early days where there's no widespread agreement and implementation on ways to rotate keys more regularly without training users to always click through any warning they see, I think using longer lived certs has definite upsides. Cheers, Solderpunk
Good to hear, thanks! Now we just have to get all the servers to switch over... makeworld ??????? Original Message ??????? On Monday, July 6, 2020 8:55 AM, Solderpunk <solderpunk at posteo.net> wrote: > On Mon Jul 6, 2020 at 12:18 AM CEST, wrote: > > > 5 year certs sound like a good compromise to me. We can make client > > messages sufficiently scary, seeing as a five year expiry will make > > TOFU issue somewhat rare. Will you set that as a default for your > > cert tool then? > > Maybe! ;) Ido plan to finally start work on that tool this week, by > the way. > > Hopefully by 2025 we'll have agreed on a way to do smooth roll-overs > which is widely implemented! If that does happen, and it's easily > automated (which I'd very much like it to be), maybe we can start > shifting towards less long-lived keys/certs for a extra peace of mind. > > > Do you agree with my original recommendation that clients should > > auto-accept any cert once the old one has expired? This seems relevant > > here. I think it's nice for UX, although I see the obvious security > > risk. > > In the absence of any other roll-over mechanism, yeah, this seems like > sane behaviour for a TOFU client. > > Cheers, > Solderpunk
On Sun, Jul 5, 2020 at 1:17 PM Solderpunk <solderpunk at posteo.net> wrote: > Using the same keypair for a very long time is generally considered a > bad idea, as it increases both the risk of key compromise and the > duration for which a stolen key can be exploited. There's also the issue of > ownership of domain names changing over long timespans, and former legitimate > domain owners being able to impersonate new legitimate domain owners with old > certificates. Even CA certificates have expiry dates. Is this actually true for TOFU certificates? SSH fingerprints don't expire [1]. Servers can still rotate key pairs without introducing the attack vector of expiring the old ones [2]. As soon as a client connects to a server and accepts the new keypair, any old certs should automatically become invalid to that client, because they're not the trusted "first-use" certificate anymore. It's not like a CA system where there can be multiple valid keypairs live at the same time. This is also true for transferring domain ownership. An attacker can only continue to exploit a client until they visit the real server. If the client never visits the real server, the attacker can just swap out the expired certificate with a new self-signed certificate and it will look like a harmless key rotation. Expiration doesn't gain you anything there. I get the point about encryption algorithms becoming insecure over time and private keys more likely to be stolen. I just don't understand the advantage to key rotation + expiring the old keys vs. simple key rotation by itself. [1] https://tools.ietf.org/html/rfc4716 [2] The attack vector being something like this: Your server rotates key pairs every 60 days and issues certificates with a 90 day expiration. I visit your server once and then don't come back for 90 days. My client sees that the fingerprint in my local TOFU database is expired, and probably accepts whatever server sends me. This scenario is dramatically lessened with > 1 year expiration times, but why allow it to happen at all? > One idea I had, which could be neat for people who are really serious > about good, long-term identity management without CAs, is the following: > generate a key pair, for use as an ephemeral signing key, and a > self-signed certificate for the public key with 100 years of validity. > Then generate 100 additional keypairs, and use the signing key to sign > certificates for them with a validity of, say, 1 year each, and > consecutive validity periods. Permanently delete the signing key, but > keep the self-signed certificate. Move all the 1 year keys to a USB > stick, and transfer them one at a time, as they become valid, to your > server. For the next 100 years, serve up a two certificate long chain, > with the self-signed cert for the signing key, plus your currently > active 1 year cert signed with the signing key. Once a client > TOFU-accepts the signing key's certificate, they'll be able to validate > all the annual key roll overs as originating from the same party, even > if they don't visit your site for 10 years at a time. Someone who > breaks into your server can steal this year's key, but not any future > keys, because they're on the USB stick, so their ability to impersonate > you is strictly time-limited. Nobody can steal the original signing key > and make their own certificate which will be accepted by TOFU clients, > because it's been deleted. Hijacking this identity basically requires > stealing the physical USB key. This sounds like a lot of work, but > generating all the keys and certs could be trivially automated. You would need some overlap in the validity periods to allow time to swap out the keys on the server. Honestly though, this sounds like an obtuse way to avoid using a CA. Once you are employing certificate chains is it really self-signed anymore? Generate your own CA with a 100-year expiration and stick *that* on the USB drive. You could even maintain your own certificate revocation list! Utilizing CAs does not need to imply trusting the root browser CAs. best, mozz
> Servers can still rotate key pairs without introducing the attack vector of > expiring the old ones [2]. > I just don't understand the advantage to > key rotation + expiring the old keys vs. simple key rotation by itself. Thanks for chiming in mozz! How can a server rotate a keypair and prove it's still the same server as before, that there's not an MITM attack going on? This is a genuine question, I haven't heard much about key rotation for TLS before. Could you explain or send a link on how this works? I can't find much on it. Thanks, makeworld
> From: Gemini <gemini-bounces at lists.orbitalfox.eu> On Behalf Of > colecmac at protonmail.com > How can a server rotate a keypair and prove it's still the same server as > before, that there's not an MITM attack going on? This is a genuine question, > I haven't heard much about key rotation for TLS before. Could you explain or > send a link on how this works? I can't find much on it. This thread feels like it's trying to hack certificate validation into doing something for which it really wasn't intended, operating without a CA. Getting this right is likely to be more complicated than any aspect of the Gemini protocol itself. The spec: > the strongly RECOMMENDED approach is to implement a lightweight "TOFU" certificate-pinning system which treats self-signed certificates as first- class citizens. This greatly reduces TLS overhead on the network (only one cert needs to be sent, not a whole chain) and lowers the barrier to entry for setting up a Gemini site (no need to pay a CA or setup a Let's Encrypt cron job, just make a cert and go). Could I gently push back on the idea that getting an LE certificate is a high barrier to entry? Configuring certbot is relatively easy and a known quantity. Cleaning up after my private key is lost or exposed is an open ended problem with no easy solutions. I know there is a diversity of opinions/priorities but my vote would be to lean on the regular CA infrastructure so that we don't have to tussle with all of the scenarios currently being discussed. More broadly, Gemini is a magnificent hack to co-opt the best of both gopher and the web into a carefully calibrated new thing, leaning on existing technologies like URLs, MIME types and TLS for expedience. LetsEncrypt is a magnificent hack to the CA system, providing all the benefits to us at no monetary cost, and that was no small undertaking. I don't think it should fall to Gemini, and therefore the implementors of Gemini clients and servers, to "fix" TLS trust. A good solution, once it is actually adopted, is likely to apply to all TLS servers rather than Gemini alone. Provided we are using TLS libraries we can take advantage of whatever that happens to be. If nothing else, clients could attempt to verify the provided cert/chain against the system's trusted root CAs. If this takes precedence over TOFU it offers an escape hatch for anybody who wanted to try the self-signed thing and then it didn't work out. Nothing I've suggested here is _contrary_ to the spec as it stands - it's just a question of what people do by default, which hopefully won't set them up for failure later. Cheers, Tom
On Tue Jul 7, 2020 at 6:26 AM CEST, Thomas Karpiniec wrote: > Could I gently push back on the idea that getting an LE certificate is a > high barrier to entry? Configuring certbot is relatively easy and a > known quantity. Cleaning up after my private key is lost or exposed is > an open ended problem with no easy solutions. I know there is a > diversity of opinions/priorities but my vote would be to lean on the > regular CA infrastructure so that we don't have to tussle with all of > the scenarios currently being discussed. This opinion has been expressed in the past - in fact, by Michael Lazar if I remember rightly? The extent to which Geminispace at large has been interested in trying to breakaway from the "centralised oligarchy of CAs" has changed. I'd love to have detail stats on the actual proportion of servers using self-signed vs CA-signd certs over time! There seems to be more enthusiasm behind TOFU at the moment than at other times in the relatively recent past. The spec is deliberately, for now, quite open ended on this. I didn't want to force people to implement TOFU, which has proven less trivial than I first imagined. But I also didn't want server operators who do choose to experiment with it to become second class citizens of Geminispace, with most clients throwing up scary warnings every time. > If nothing else, clients could attempt to verify the provided cert/chain > against the system's trusted root CAs. If this takes precedence over > TOFU it offers an escape hatch for anybody who wanted to try the > self-signed thing and then it didn't work out. Nothing I've suggested In generally agree with you here. This allows folks without philosophical/political axes to grind to just setup certbot and know it will work smoothly (which it doesn't with pure TOFU clients, which will trigger warnings regularly) The only reason AV-98 doesn't do this, and forces you to manually switch between the two modes, is that the standard Python ssl module doesn't allow it (at least not gracefully, without making a new connection after one fails). > This thread feels like it's trying to hack certificate validation into > doing something for which it really wasn't intended, operating without a > CA. Getting this right is likely to be more complicated than any aspect > of the Gemini protocol itself. I have been thinking this myself lately. Not that I want to give up on TOFU, but that all the more clever/elegant ways of doing it which involve certificate chains are actually not the way to go: they might be solid security wise, but no TLS library is going to support them out of the box. They *might* be easily implemented with a library which exposes signature validation functions nicely, but those will be rare, and further more programmers who understand how to do that properly will be even rarer, running the risk of bad implementations. My current thinking is that any recommended approach should avoid treating certificates as anything more than than opaque binary blobs as much as possible (for the purposes of trust management, I mean). The various ideas around serving future certificates on a well-known endpoint for some time before they become valid fits in with this. It just involves fetching a pile of bytes and hashing it, no understanding of keys/signing on the part of the client author required... > A good solution, once it > is actually adopted, is likely to apply to all TLS servers rather than > Gemini alone. I'm not too sure about this. Solutions which work in an environment dominated by dissemination of publically available information (Geminispace, I hope) may not work acceptably well in an environment dominated by private conversations (email, and a lot of the web). I suspect it's a lot easier to come up with something relatively simple that works for us which most other TLS servers will be disinterested in. Cheers, Solderpunk
On Tue Jul 7, 2020 at 5:20 AM CEST, Michael Lazar wrote: > Servers can still rotate key pairs without introducing the attack vector > of > expiring the old ones [2]. As soon as a client connects to a server and > accepts > the new keypair, any old certs should automatically become invalid to > that > client, because they're not the trusted "first-use" certificate anymore. > It's > not like a CA system where there can be multiple valid keypairs live at > the > same time. This is also true for transferring domain ownership. You're right that TOFU clients should in general only have a single actively trusted key on record for each server. I guess I see the main utility of explicit expiration dates in this context as being a kind of promise from the sever admin that "I have no plans to do a key rotation for about this length of time". This means that apparent MITM attacks happening at a time when there's a lot of validity left can be treated with much higher suspicion. > You would need some overlap in the validity periods to allow time to > swap out > the keys on the server. Sure. > Honestly though, this sounds like an obtuse way to avoid using a CA. > Once you > are employing certificate chains is it really self-signed anymore? > Generate > your own CA with a 100-year expiration and stick *that* on the USB > drive. Well, that's sort of what that idea is, at core: being your own CA. TOFU clients treating certificates that they've trusted once as CAs of very limited power (only able to sign future certs for that one domain, and perhaps only good for a single signature) is an interesting way to get from "trusting on blind faith everytime a new cert comes down the line" to "trusting on blind faith once at the very beginning and then building up strong trust over time that you're always interacting with the same party". That second situation, if we can get there, is, I would argue, good enough for Geminispace - and, arguably, a lot more like how trust in the real world works. Cheers, Solderpunk
A proposal: "TOFU-TOTS". You know, like tater tots, but without potatoes in them. Or rather, trust-on-first-use augmented by trust-over-time-and-space. Desiderata:
On Tue, Jul 07, 2020 at 11:30:20AM +0200, Solderpunk wrote: > I'd love to have detail stats on the actual proportion of servers > using self-signed vs CA-signd certs over time! There seems to be > more enthusiasm behind TOFU at the moment than at other times in the > relatively recent past. I can gladly start tracking this with the next GUS crawl, but we're getting beyond my expertise. I have a very lightly modified version [0] of Jason McBrayer's gusmobile [1] (in Python) that I think has been, thankfully, the sole arbiter of all things TLS for GUS. If anyone is interested in altering that code, or helping me figure out how to alter that code, to return info on self-signed vs CA-signed distinctions, we could get statistics on this soon. [0] https://git.sr.ht/~natpen/gusmobile [1] https://git.carcosa.net/jmcbray/gusmobile/
Natalie Pendragon <natpen at natpen.net> writes: > I can gladly start tracking this with the next GUS crawl, but we're > getting beyond my expertise. I have a very lightly modified version > [0] of Jason McBrayer's gusmobile [1] (in Python) that I think has > been, thankfully, the sole arbiter of all things TLS for GUS. If > anyone is interested in altering that code, or helping me figure out > how to alter that code, to return info on self-signed vs CA-signed > distinctions, we could get statistics on this soon. > > [0] https://git.sr.ht/~natpen/gusmobile > [1] https://git.carcosa.net/jmcbray/gusmobile/ If your modifications are generally useful, would you be willing to submit a pull request (or just a git-send-email patch)? I've kind of neglected gusmobile, to the point that it has an actual long-standing bug that has to be worked around for the most trivial use-case. I've been meaning to fix it, but I have so little time for hobby hacking. -- +-----------------------------------------------------------+ | Jason F. McBrayer jmcbray at carcosa.net | | A flower falls, even though we love it; and a weed grows, | | even though we do not love it. -- Dogen |
> A proposal: "TOFU-TOTS". You know, like tater tots, but without > potatoes in them. Or rather, trust-on-first-use augmented by > trust-over-time-and-space. I like this proposal, and I want to digest it more fully later, but it also seems like this complicates what's already the most complicated part of Gemini. Is this an optional special idea, like notaries, or are you hoping this gets more widespread use? Personally, I like the simpler ideas that have been used so far, combined with something like 5 year certs. makeworld P.S. Can anyone explain or give me a link on TLS key rotation? How is it different from changing certs?
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/f3df 19bb/attachment-0001.htm>
On Tue, Jul 07, 2020 at 10:03:31AM -0400, Jason McBrayer wrote: > If your modifications are generally useful, would you be willing to > submit a pull request (or just a git-send-email patch)? I've kind of > neglected gusmobile, to the point that it has an actual long-standing > bug that has to be worked around for the most trivial use-case. I've > been meaning to fix it, but I have so little time for hobby hacking. Sure, patches incoming! You can pick and choose anything that looks useful, but honestly the reason I hadn't already submitted these changes upstream is that most of them are hacks to make Gusmobile and GUS play well together.
Natalie Pendragon <natpen at natpen.net> writes: > On Tue, Jul 07, 2020 at 10:03:31AM -0400, Jason McBrayer wrote: >> If your modifications are generally useful, would you be willing to >> submit a pull request (or just a git-send-email patch)? I've kind of >> neglected gusmobile, to the point that it has an actual long-standing >> bug that has to be worked around for the most trivial use-case. I've >> been meaning to fix it, but I have so little time for hobby hacking. > > Sure, patches incoming! You can pick and choose anything that looks > useful, but honestly the reason I hadn't already submitted these > changes upstream is that most of them are hacks to make Gusmobile and > GUS play well together. Thanks, I super appreciate your work! -- +-----------------------------------------------------------+ | Jason F. McBrayer jmcbray at carcosa.net | | A flower falls, even though we love it; and a weed grows, | | even though we do not love it. -- Dogen |
> On Jul 7, 2020, at 11:30, Solderpunk <solderpunk at posteo.net> wrote: > > My current thinking is that any recommended approach should avoid > treating certificates as anything more than than opaque binary blobs as > much as possible Perhaps of interest: Using Raw Public Keys in Transport Layer Security (TLS) https://tools.ietf.org/html/rfc7250
On Wed, Jul 8, 2020 at 4:57 PM Petite Abeille <petite.abeille at gmail.com> wrote: > > Perhaps of interest: > > Using Raw Public Keys in Transport Layer Security (TLS) > https://tools.ietf.org/html/rfc7250 Yes. Looks interesting, and it goes in the right direction. Unfortunately, the RFC is already quite old (2014) and according to Wikipedia, it is only supported by GnuTLS (I didn't check directly). Do you know if it is already used in some visible applications? Phil
On Wed, Jul 8, 2020 at 6:25 PM Phil Leblanc <philanc at gmail.com> wrote: > according to Wikipedia, [RFC 7250] is only supported by GnuTLS see https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations > Phil
> On Jul 8, 2020, at 20:25, Phil Leblanc <philanc at gmail.com> wrote: > > Yes. Looks interesting, and it goes in the right direction. > Unfortunately, the RFC is already quite old (2014) and according to > Wikipedia, it is only supported by GnuTLS (I didn't check directly). > > Do you know if it is already used in some visible applications? Hmm, no :) Just stumbled upon it on the openssl mailing list, where someone was asking if it was supported: RFC 7250 raw public keys? https://www.mail-archive.com/openssl-users at openssl.org/msg88412.html There is an open issue for it: Raw Public Key (RFC 7250) support https://github.com/openssl/openssl/issues/6929 mbedtls seems to have something: Support Raw Public Key mode (RFC7250) https://github.com/ARMmbed/mbedtls/pull/336
Thanks for sharing this! I will read it closely. It's a shame if it's not widely implemented, but there may well still be good ideas in there, or details we've overlooked. Cheers, Solderpunk On Wed Jul 8, 2020 at 11:27 PM CEST, Petite Abeille wrote: > > > > On Jul 8, 2020, at 20:25, Phil Leblanc <philanc at gmail.com> wrote: > > > > Yes. Looks interesting, and it goes in the right direction. > > Unfortunately, the RFC is already quite old (2014) and according to > > Wikipedia, it is only supported by GnuTLS (I didn't check directly). > > > > Do you know if it is already used in some visible applications? > > Hmm, no :) Just stumbled upon it on the openssl mailing list, where > someone was asking if it was supported: > > RFC 7250 raw public keys? > https://www.mail-archive.com/openssl-users at openssl.org/msg88412.html > > > There is an open issue for it: > > Raw Public Key (RFC 7250) support > https://github.com/openssl/openssl/issues/6929 > > > mbedtls seems to have something: > > Support Raw Public Key mode (RFC7250) > https://github.com/ARMmbed/mbedtls/pull/336
On Tue Jul 7, 2020 at 4:34 PM CEST, wrote: > I like this proposal, and I want to digest it more fully later, but > it also seems like this complicates what's already the most complicated > part of Gemini. Is this an optional special idea, like notaries, or are > you hoping this gets more widespread use? Oh! I had thought of this as a relatively simple idea, simpler than anything involving signatures to validate new keys. > Personally, I like the simpler ideas that have been used so far, > combined > with something like 5 year certs. What are the simpler ideas? Just straight up TOFU with a scary message five years later? Cheers, Solderpunk
> On Jul 9, 2020, at 00:18, Solderpunk <solderpunk at posteo.net> wrote: > > Thanks for sharing this! I will read it closely. It's a shame if it's > not widely implemented, but there may well still be good ideas in there, > or details we've overlooked. Another link, as a counterexample of what we are trying to escape from: Path Building vs Path Verifying: The Chain of Pain https://medium.com/@sleevi_/path-building-vs-path-verifying-the-chain-of-pa in-9fbab861d7d6 The Chain of Pain! :D
> On Jul 8, 2020, at 20:25, Phil Leblanc <philanc at gmail.com> wrote: > > GnuTLS GNU: A Heuristic for Bad Cryptography https://soatok.blog/2020/07/08/gnu-a-heuristic-for-bad-cryptography/ Ah!
On Wed, Jul 8, 2020 at 9:27 PM Petite Abeille <petite.abeille at gmail.com> wrote: > > mbedtls seems to have something: > > Support Raw Public Key mode (RFC7250) > https://github.com/ARMmbed/mbedtls/pull/336 I downloaded mbedtls (the development branch) one week ago (2020-07-01). I grepped through the tree and found no sign of RFC7250 or RPK :-(
On Wed, Jul 8, 2020 at 11:08 PM Petite Abeille <petite.abeille at gmail.com> wrote: > > GNU: A Heuristic for Bad Cryptography > https://soatok.blog/2020/07/08/gnu-a-heuristic-for-bad-cryptography/ > > Ah! Nice :-)
On Wednesday, July 8, 2020 6:19 PM, Solderpunk <solderpunk at posteo.net> wrote: > [...] > > Personally, I like the simpler ideas that have been used so far, > > combined > > with something like 5 year certs. > > What are the simpler ideas? Just straight up TOFU with a scary message > five years later? Yes, I see that as a lot simpler. It doesn't require a well known endpoint, or a background service for clients, etc. But I still like the idea. makeworld
> From: Gemini <gemini-bounces at lists.orbitalfox.eu> On Behalf Of Solderpunk > A proposal: "TOFU-TOTS". You know, like tater tots, but without > potatoes in them. Or rather, trust-on-first-use augmented by > trust-over-time-and-space. Setting aside that I already put my support behind the oligarchy, this is an interesting problem and I'll weigh in. :) I agree that that this proposal would provide fairly effective protection against MITM. I worry that it is so unusual that it would push newbies away from setting up gemini servers. Faced with regular rotation requirements I suspect that many people would automate the process with cronjobs, meaning that the keys for the next certificate are sitting right there on the server ready to be nabbed. More annoyingly, suppose the current private key is compromised and the legitimate server owner realises it - they don't have any good options. One is to put up with being spoofable until their next-advertised certificate becomes valid, which may be 10 months in the future. Otherwise they could do an out-of-turn certificate rotation, which clients will warn on just as harshly as any other unexpected change. (Further down the thread, Baschdel suggested backup certificates to alleviate this. But what if you're compromised twice? To me the complexity creep feels disproportionate to the advantages.) A suggestion: what if instead of publishing a future certificate, we publish our own CA certificate, which is used to sign our server certificates? A client should cache this CA certificate permanently and use it to verify all future requests to that domain. A diligent system administrator will keep their CA key material offline. Someone who doesn't care so much can just generate everything on their server.
If you're willing to look at unusual uses of TLS, I'll mention that there's also an RFC for OpenPGP-based TLS encryption. This is not a recommendation! https://tools.ietf.org/html/rfc6091 That would allow web-of-trust based infrastructure. But as there are no widespread implementations, it will be a pain to use in practice. In my very humble opinion, a community-based distributed trust system is safer than TOFU and more suitable for non-commercial use than CA based PKI. But in practice *any* TLS is much, much safer than plaintext as it completely prevents eavesdropping without a full-fledged MitM attack. A more practical way of building a web of trust upon TOFU would be for browsers to export cert fingerprint lists that people can share on their sites. These could be compared and imported, and with some human interaction we should notice when MitM attacks start happening in practice. -Hannu On Thu, 9 Jul 2020 at 01:19, Solderpunk <solderpunk at posteo.net> wrote: > Thanks for sharing this! I will read it closely. It's a shame if it's > not widely implemented, but there may well still be good ideas in there, > or details we've overlooked. > > Cheers, > Solderpunk > > On Wed Jul 8, 2020 at 11:27 PM CEST, Petite Abeille wrote: > > > > > > > On Jul 8, 2020, at 20:25, Phil Leblanc <philanc at gmail.com> wrote: > > > > > > Yes. Looks interesting, and it goes in the right direction. > > > Unfortunately, the RFC is already quite old (2014) and according to > > > Wikipedia, it is only supported by GnuTLS (I didn't check directly). > > > > > > Do you know if it is already used in some visible applications? > > > > Hmm, no :) Just stumbled upon it on the openssl mailing list, where > > someone was asking if it was supported: > > > > RFC 7250 raw public keys? > > https://www.mail-archive.com/openssl-users at openssl.org/msg88412.html > > > > > > There is an open issue for it: > > > > Raw Public Key (RFC 7250) support > > https://github.com/openssl/openssl/issues/6929 > > > > > > mbedtls seems to have something: > > > > Support Raw Public Key mode (RFC7250) > > https://github.com/ARMmbed/mbedtls/pull/336 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200709/3128 bd33/attachment.htm>
A thought from one without enough knowledge to have a right to thoughts:
Getting broad acceptance of Gemini both theoretically as a viable
standard and practically as a growing community is important. Having
community members developing their own clients and servers - not so much.
I am sure I will always be using a client which someone else wrote, just
as I use a web browser someone else wrote. And I am dead certain I will
never try to write my own server, as I will never try to write my own
Apache.
Best to all,
Terry B.
On 07/08/2020 08:39 PM, Thomas Karpiniec wrote:
>> From: Gemini <gemini-bounces at lists.orbitalfox.eu> On Behalf Of Solderpunk
>> A proposal: "TOFU-TOTS". You know, like tater tots, but without
>> potatoes in them. Or rather, trust-on-first-use augmented by
>> trust-over-time-and-space.
> Setting aside that I already put my support behind the oligarchy, this
is an interesting problem and I'll weigh in. :)
>
> I agree that that this proposal would provide fairly effective
protection against MITM. I worry that it is so unusual that it would push
newbies away from setting up gemini servers. Faced with regular rotation
requirements I suspect that many people would automate the process with
cronjobs, meaning that the keys for the next certificate are sitting right
there on the server ready to be nabbed.
>
> More annoyingly, suppose the current private key is compromised and the
legitimate server owner realises it - they don't have any good options.
One is to put up with being spoofable until their next-advertised
certificate becomes valid, which may be 10 months in the future. Otherwise
they could do an out-of-turn certificate rotation, which clients will warn
on just as harshly as any other unexpected change. (Further down the
thread, Baschdel suggested backup certificates to alleviate this. But what
if you're compromised twice? To me the complexity creep feels
disproportionate to the advantages.)
>
> A suggestion: what if instead of publishing a future certificate, we
publish our own CA certificate, which is used to sign our server
certificates? A client should cache this CA certificate permanently and
use it to verify all future requests to that domain. A diligent system
administrator will keep their CA key material offline. Someone who doesn't
care so much can just generate everything on their server.
>
> * Client logic is simpler
> * Keys and certificates can be rotated at will by the sysadmin and they
can choose whatever expiry they are comfortable with
> * Relies on familiar concepts of TLS trust ("oh I'm my own CA, okay")
and sysadmins can choose their own level of caution
> * Uses the existing feature of TLS libraries to verify a connection
against a given CA. Clients don't have to handle public keys or
fingerprints - they just download the CA certificate and feed it into their TLS library.
> * Combines neatly with LetsEncrypt-style certificate management - you
are just adding one extra trusted CA. If it can be verified by either
that, or one of the normal roots, then you're okay.
> * Only slightly more complicated openssl commands required when setting up a server
>
> Cheers, Tom
On Thu Jul 9, 2020 at 1:25 AM CEST, wrote: > > What are the simpler ideas? Just straight up TOFU with a scary message > > five years later? > > > Yes, I see that as a lot simpler. It doesn't require a well known > endpoint, or > a background service for clients, etc. But I still like the idea. I guess it will always be up to individual server admins to decide how they want to balance the effort involved in different setups against what kind of user experience they're happy for their visitors to have, and how they perceive their risk of someone trying to impersonate them. All we can really do is lay out the various options along the scale, and perhaps recommend one in particular as the "go to" choice for people who don't feel up to making the decision. Cheers, Solderpunk
---