Post ATvshNZpdLyPysIUb2 by LucaFilipozzi@fosstodon.org
 (DIR) More posts by LucaFilipozzi@fosstodon.org
 (DIR) Post #ATvnxMIrda32tRA2pU by mjg59@nondeterministic.computer
       2023-03-24T05:50:35Z
       
       0 likes, 0 repeats
       
       https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/ - urgh this could be avoided if the state of the SSH certificate ecosystem were better
       
 (DIR) Post #ATvoDSrn0EylslB1pA by mjg59@nondeterministic.computer
       2023-03-24T05:53:55Z
       
       0 likes, 0 repeats
       
       Being able to say "I trust any certificate signed by this key for any github.com address" would mean not having to fundamentally trust specific RSA private keys, and short expiry periods mean revocation isn't a real issue. Keep the certificate signing key in an HSM with appropriate auditing.
       
 (DIR) Post #ATvoQPGfh5PuUAzDxA by mjg59@nondeterministic.computer
       2023-03-24T05:54:27Z
       
       0 likes, 0 repeats
       
       You can do this now, but it involves writing out manual SSH config so it's not realistic in the github case.
       
 (DIR) Post #ATvojYUBe6WSZpRHJg by mjg59@nondeterministic.computer
       2023-03-24T05:59:36Z
       
       0 likes, 0 repeats
       
       @nogweii You could certainly glue some of it into that, but there's a deliberate choice to make the SSH certificate format *much* simpler than x509 (and hence webPKI) to reduce the risk of parsing bugs
       
 (DIR) Post #ATvoqhO8wduYDN1Cts by realmurphy@social.linux.pizza
       2023-03-24T05:59:40Z
       
       0 likes, 0 repeats
       
       @mjg59 and even if they did it, there is no way to enforce users to use it (to my very limited knowledge).And as people are too lazy, most will not even bother unless it was enforced.
       
 (DIR) Post #ATvoxXuOaZdwqBMx2O by offby1@wandering.shop
       2023-03-24T06:00:08Z
       
       0 likes, 0 repeats
       
       @mjg59 I'm curious what you mean here.
       
 (DIR) Post #ATvp4D7SHWUGOHeiES by mjg59@nondeterministic.computer
       2023-03-24T06:02:23Z
       
       0 likes, 0 repeats
       
       @offby1 $ git clone ssh://github.com/whatever"github.com has provided a certificate signed with CA key (whatever). Do you want to trust this CA for this domain? (yes/no)"and then even if the keys on github.com change, as long as they have a valid certificate from the same CA it'd still work. Right now you need to write explicit configuration to express that.
       
 (DIR) Post #ATvpB5C88xLfq97SfA by Viss@mastodon.social
       2023-03-24T06:03:29Z
       
       0 likes, 0 repeats
       
       @mjg59 the letsencrypt model?
       
 (DIR) Post #ATvpIGqFEqqbzQJHTE by liw@toot.liw.fi
       2023-03-24T06:04:54Z
       
       0 likes, 0 repeats
       
       @mjg59 Do you mean a manual config for the client? The line to add to `known_hosts`?
       
 (DIR) Post #ATvpOxc57z6WNfsKVk by mjg59@nondeterministic.computer
       2023-03-24T06:07:12Z
       
       0 likes, 0 repeats
       
       @liw Yes, adding an appropriate @cert-authority to known_hosts is necessary right now
       
 (DIR) Post #ATvqI8hhavIYhlocj2 by kevinriggle@ioc.exchange
       2023-03-24T06:17:09Z
       
       0 likes, 0 repeats
       
       @mjg59 in much the same way that all software projects started in whatever language eventually come to read like Java, all PKIs eventually recapitulate the web PKI
       
 (DIR) Post #ATvqnlal3lw4I6eGem by offby1@wandering.shop
       2023-03-24T06:22:46Z
       
       0 likes, 0 repeats
       
       @mjg59 does the manual ssh config have to be on the server side or on the host side?
       
 (DIR) Post #ATvrOemXLHFjsukT20 by ankitpati@mastodon.social
       2023-03-24T06:29:21Z
       
       0 likes, 0 repeats
       
       @mjg59 Why are keys committed to repositories at all?Also, “inadvertently published” is blameless language (which is a good thing) for “a developer pushed it,” which means a GitHub devs have the private keys on their workstations or dev VMs.
       
 (DIR) Post #ATvrVum4HUGBVlzRmC by kevinreddot@ioc.exchange
       2023-03-24T06:29:29Z
       
       0 likes, 0 repeats
       
       @mjg59 there is SSHFP DNS record type that could work too, if DNSSEC was not in such sad state.
       
 (DIR) Post #ATvsacMCHd6XnFhBfk by liw@toot.liw.fi
       2023-03-24T06:42:46Z
       
       0 likes, 0 repeats
       
       @mjg59 I am interested in helping fix that, but I lack ideas for how to that. Would you have suggestions or opinions?Document the process better?Add tooling to automate it for the user?Create packages for various ecosystems to make the configuration change?All of the above?Something else?
       
 (DIR) Post #ATvshNZpdLyPysIUb2 by LucaFilipozzi@fosstodon.org
       2023-03-24T06:43:17Z
       
       0 likes, 0 repeats
       
       @mjg59 do they publish SSHFP records?
       
 (DIR) Post #ATvsnTG3QOkpKzx2FU by mjg59@nondeterministic.computer
       2023-03-24T06:44:45Z
       
       0 likes, 0 repeats
       
       @liw One option would be to support adding CA keys to known_hosts rather than  just keys, but I think the hard bit is figuring out what kind of wildcards could be supported for that (I guess you could just do as the current known_hosts does and only add for the specific host, not anything broader)
       
 (DIR) Post #ATvtHkWFoPzdYmxyam by liw@toot.liw.fi
       2023-03-24T06:50:36Z
       
       0 likes, 0 repeats
       
       @mjg59 I think I'm misunderstanding something. I thought I'm already adding the CA public key to my known hosts. What am I getting wrong?
       
 (DIR) Post #ATvuFQQ9fNacbKZLm4 by mjg59@nondeterministic.computer
       2023-03-24T07:01:22Z
       
       0 likes, 0 repeats
       
       @liw You're adding the host's public key, not the CA key
       
 (DIR) Post #ATvuouzK0gvBXTwV1c by liw@toot.liw.fi
       2023-03-24T07:07:49Z
       
       0 likes, 0 repeats
       
       @mjg59 I don't think I am:@cert-authority * ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIW1QmBC3OLsjpUv1gIYBHSN5tWhPOHHzDIXgj8d1Hg1That key is to CA key, not the host key. For my own CA that signs the host keys of all of my own hosts.I don't have any host keys of my own hosts in my known hosts file, only those that other people run.
       
 (DIR) Post #ATvuyfHHHAAdi4zMrw by mjg59@nondeterministic.computer
       2023-03-24T07:09:40Z
       
       0 likes, 0 repeats
       
       @liw Er. How did that get there? It would definitely be terrifying if ssh automatically added a wildcard CA key.
       
 (DIR) Post #ATvvBnUC4KAOvrIB0q by aris@infosec.exchange
       2023-03-24T07:11:57Z
       
       0 likes, 0 repeats
       
       @mjg59 There's a built-in key rotation system in SSH that permits hosts to push new host keys to the client, alas it only works when the user connects during the transition period.But they're using libssh which doesn't have 100% of these features implemented. Having RSA users (= a minority of them) manually rotate the keys is a minor doesn't look so bad in the end.
       
 (DIR) Post #ATvvItRwIJntSHcaaO by mjg59@nondeterministic.computer
       2023-03-24T07:12:50Z
       
       0 likes, 0 repeats
       
       @liw The issue is that the friction to add a new host key is very low (you type "yes" on first login) but there's no equivalent mechanism to add a CA key for a host
       
 (DIR) Post #ATvvPhXsx5IyYveIRU by liw@toot.liw.fi
       2023-03-24T07:14:15Z
       
       0 likes, 0 repeats
       
       @mjg59 I added it manually, of course. The wildcard is there because I trust myself as the CA, and I don't have a domain for most of my hosts, just a hostname (VMs running locally).I agree the wildcard is a problem. For a publicly used service like GitHub, I'd use "github.com" as the pattern, of course.
       
 (DIR) Post #ATvvVoPULImdaddRTM by mjg59@nondeterministic.computer
       2023-03-24T07:15:05Z
       
       0 likes, 0 repeats
       
       @liw Yes, but you'd have to do that manually, which means nobody does it
       
 (DIR) Post #ATvvWAM2kn6FeKC09o by mjg59@nondeterministic.computer
       2023-03-24T07:15:30Z
       
       0 likes, 0 repeats
       
       @liw If ssh could automatically generate @cert-authority entries then key rotation would be much easier
       
 (DIR) Post #ATvx347H4HSJoQXI2a by liw@toot.liw.fi
       2023-03-24T07:32:46Z
       
       0 likes, 0 repeats
       
       @mjg59 Gotcha. I agree. It would be handy if the ssh client offered to add a line to the known hosts file that adds the certificate, not just the host key. The client already knows if the server offers a certificate, and I"m assuming the client can extract the CA public key from the certificate, but if not, that seems like it could be added.
       
 (DIR) Post #ATvxsAEE6RO3XO9Zho by chrysn@chaos.social
       2023-03-24T07:41:55Z
       
       0 likes, 0 repeats
       
       @mjg59 @liw I think it'd suffice if the server could offer multiple keys and announce with the old key that it has the new key available (both for rotation and algorithm updates); if a server at some point gets configured to announce "@cert..." that'd be a good next step.
       
 (DIR) Post #ATw00ZDLI3K9FpsHWS by me@social.taupehat.com
       2023-03-24T08:05:48Z
       
       0 likes, 0 repeats
       
       @mjg59 oh for crying out loud. Forget for a moment about the whole cert ecosystem (a problem which books could be written about) and let's just wonder who in hell accidentally published GitHub's private key in a repo. Maybe they'll figure out ways to limit access to that kind of data? Good grief!
       
 (DIR) Post #ATw33W2Pr6Qq8PrTRQ by isomer@fosstodon.org
       2023-03-24T08:40:07Z
       
       0 likes, 0 repeats
       
       @mjg59 @offby1 hey @djm I don't see you on this thread yet.  Do you have an opinion on this?
       
 (DIR) Post #ATxDrtlxwUuS2VF6ye by djm@cybervillains.com
       2023-03-24T10:09:37Z
       
       0 likes, 0 repeats
       
       @isomer @mjg59 @offby1 my opinion is basically https://cybervillains.com/@djm/110077675622139561OpenSSH already supports graceful key rotation that could have helped GitHub avoid breaking clients. However they don't use OpenSSH for serving and AFAIK haven't implemented the protocol extension (which has other benefits) for their server.
       
 (DIR) Post #ATxDs8xrSYKz9jvK6K by isomer@fosstodon.org
       2023-03-24T13:10:06Z
       
       0 likes, 0 repeats
       
       @djm @mjg59 @offby1 hmm. So:T0: Alice connects to GitHub and tofu's Key1 and learns KeyB (backup).T1: GitHub accidentally publishes the secret part of Key1.T2: GitHub accepts Key1 and a new Key2 and continues to teach about Key2 and KeyBT3: GitHub stops accepting Key1.
       
 (DIR) Post #ATxDsJ2U0DyaOyA9h2 by isomer@fosstodon.org
       2023-03-24T13:13:55Z
       
       0 likes, 0 repeats
       
       @djm @mjg59 @offby1 AIUI: A) the private part of KeyB needs to be online to answer proof challenges.  So KeyB would probably also been compromised.B) Nothing says to Alice to stop trusting Key1 anywhere.  So while Alice may transparently move to using Key2 when talking to GitHub Mallory can still trick Alice into accepting Key1 as valid GitHub?  There would need to be manual action to remove Key1 from known_hosts?
       
 (DIR) Post #ATxDsVhguq4LgFXEae by djm@cybervillains.com
       2023-03-24T22:13:10Z
       
       0 likes, 0 repeats
       
       @isomer @mjg59 @offby1 the key rotation support means that the client would _already have_ alternate keys for the endpoint and that Github could have stopped serving RSA keys to them. They could have identified the clients that supported the extension via SSH- banner string
       
 (DIR) Post #ATxDscKYHGieEVlLzk by mjg59@nondeterministic.computer
       2023-03-24T22:15:52Z
       
       0 likes, 0 repeats
       
       @djm @isomer @offby1 my understanding was that you couldn't just pre-announce the public keys, but that the servers also needed the private keys to prove possession to the client - if so, isn't it just a question of whether someone accidentally commits both keys rather than only one of them?
       
 (DIR) Post #ATxDseGj4SqaFDzKJE by isomer@fosstodon.org
       2023-03-24T13:17:21Z
       
       0 likes, 0 repeats
       
       @djm @mjg59 @offby1 (or am I missing something? Is the client supposed to remove all the keys that it's not taught about?)C) when does GitHub stop accepting the compromised Key1, if ever?Don't get me wrong, this is super cool and especially useful for transparently upgrading to new keys over time, and it solves a bit of githubs problem (how do you build trust in the new key), but it seems it still leaves some problems.
       
 (DIR) Post #ATxDskCh0NBaeS9Br6 by isomer@fosstodon.org
       2023-03-24T13:20:12Z
       
       0 likes, 0 repeats
       
       @djm @mjg59 @offby1 (I mean mjg's solution is not much better but it does allow the old key to expire after a while, and the CA key doesn't have to be online.  It's also a client side only change rather than requiring server support.The downside is trying to figure out what the trust scope of the CA key should be.  If it's the domain then the client needs at least a copy of the public domain prefix list)
       
 (DIR) Post #ATxECbtpac8CginWV6 by djm@cybervillains.com
       2023-03-24T22:19:29Z
       
       0 likes, 0 repeats
       
       @mjg59 @isomer @offby1 right - key rotation requires online proof of possession of the private key.In this case however, it was just one of them leaked - the RSA key and not the ECDSA or Ed25519 keys.
       
 (DIR) Post #ATxEDODJxSF4X4HlXk by mjg59@nondeterministic.computer
       2023-03-24T15:09:48Z
       
       0 likes, 0 repeats
       
       @me the easiest way to ensure key material can't end up in the wrong place is to make it impossible to do so, which means using certificates
       
 (DIR) Post #ATxEEURAIzik7hHmYy by mjg59@nondeterministic.computer
       2023-03-24T15:10:42Z
       
       0 likes, 0 repeats
       
       @chrysn @liw that's actually supported already, but if the old key is potentially compromised then you shouldn't use it as a way to establish trust in a new key!
       
 (DIR) Post #ATxFh553l8Yrpj8wRU by zmanji@mastodon.online
       2023-03-24T11:19:20Z
       
       0 likes, 0 repeats
       
       @mjg59 the moment i saw the post i came here to see if you posted about certificates. I really wish the whole ecosystem would evolve here.
       
 (DIR) Post #ATxGJB1A8Ku3FdUBIO by bk2204@mastodon.social
       2023-03-24T22:43:02Z
       
       0 likes, 0 repeats
       
       @mjg59 I would love for GitHub to do this, but frankly, there are so many SSH implementations where RSA with SHA-2, AEADs, and EtM MACs are all missing, and there's just no practical chance of getting certificates implemented.  And because RSA with SHA-2 isn't implemented, there'd be no secure way to sign an RSA cert even if they were.
       
 (DIR) Post #ATxHLe6L4YzVz9eFmq by mjg59@nondeterministic.computer
       2023-03-24T22:54:50Z
       
       0 likes, 0 repeats
       
       @bk2204 Clients that don't support this still end up having miserable key transition experiences, but it's much better for everyone else
       
 (DIR) Post #ATxJhAXDsdD6Z9c7G4 by bk2204@mastodon.social
       2023-03-24T23:21:02Z
       
       0 likes, 0 repeats
       
       @mjg59 True, but because there are clients which do support certs and don't support RSA with SHA-2, enabling them breaks lots of existing clients, including many older OpenSSH versions.
       
 (DIR) Post #ATxKEWdQjWwefGQH2m by mjg59@nondeterministic.computer
       2023-03-24T23:27:16Z
       
       0 likes, 0 repeats
       
       @bk2204 I think the client sends version data before key exchange? It's not nice, but you could simply not send the certs for old crap.
       
 (DIR) Post #ATxXt6w2ULHWEcoHD6 by penguin42@mastodon.org.uk
       2023-03-24T14:46:35Z
       
       0 likes, 0 repeats
       
       @mjg59 @liw ssh has a bunch of helper scripts these days (like ssh-copy-id) so I guess it just needs another like that?