Hacker News Reader

Comment by justeleblanc | Hacker News Reader

I'm always amazed at this kind of posts. Did these 50 million users (surely none of them use git+https!) check the host key the first time they connected to github? Did you?

View on HN

The point being made here is that because there are millions of users forced to change keys now all at around the same time, and because they are doing so due to seeing an error in Git, this creates a good opportunity to strike. Normally, most users would have connected to GitHub before and a MITM attack has a high chance of failure.

It doesn't matter because it didn't change! That's the beauty of TOFU.

The point is, what if it you were MITMed from the beginning?

Sure, but the difference is that it's now both a plausible moment to go MITM (because they got that key), and furthermore the hypothetical attacker now has good reason to believe users won't be scared by a host-key-change warning, and the hypothetical attacker would know this opportunity exists for a large set of users simultaneously. If some malicious network operator were to try and exploit users, now would be a good moment - they'd likely catch many more people in the time it takes to be discovered than on an average day.

The MITM-at-the-start risk is of course real, but I think this new everyone -restarts-simultaneously risk is qualitatively different enough to be worth at least considering.

Much more concerningly, there is an activated-by-default OpenSSH extension (`UpdateHostKeys`) that allows the server to install new host keys into `.ssh/known_hosts` after every successful server authentication.

The bad guys would also have to have MITMed it every time I connected for the last 15 years, or I would have seen authentication failures when it connected to the real thing. MITMing someone once isn't that hard, but doing it consistently is.

It doesn't matter because it didn't change! That's the beauty of TOFU.

One way to solve this in TOFU is to have a time window where both keys are presented.

If we're starting from the assumption that the first key was compromised, then you're still vulnerable to MITM. The only solution is communicating the key through a different, trusted way. Which is exactly what github did - inasmuch you can trust that github.com is github.

> Did you?

I sure did. Doesn’t everyone?

> (surely none of them use git+https!)

well, yes

github doesn't accept https push any more

Not sure what you mean. You can push via HTTPS: https://docs.github.com/en/get-started/getting-started-with-...

Maybe you’re referring to how they no longer accept passwords for HTTPS auth? You have to auth for HTTPS push with a personal access token.

That's funny, I do it every day. It's frankly easier to install git credential manager (even integrate into WSL) for 2FA authentication on Github (and other git hosts).

I get a bit paranoid when having to deal with Tokens on various CI/CD environments as it stands. And the things that start breaking every year when I forget to update them. Note: this is personal/hobby projects, not corporate stuff, where I'm strictly in the codebase and try to keep my fingers out of CI/CD beyond getting a Docker image built, and someone else configures the keys/auth.

How are you using git credential manager for 2fa on GitHub? They stopped supporting user/password auth for HTTPS git access a while back, and started requiring personal access tokens (which do not require a 2nd factor)

GCM will use an embedded browser so you can authenticate with the UI including your second factor, which will then give you a credential/token that can be used in the git environment over HTTPS. It's still a (differt, oath vs reference generation) token, but you aren't having to go generate, configure and update it yourself.

Reply on news.ycombinator.com