Garrett: We need better support for SSH host certificates

Posted Mar 26, 2023 19:53 UTC (Sun) by cjcox (guest, #60378)
Parent article: Garrett: We need better support for SSH host certificates

It's very true that the current system didn't expect someone to drop their pants.

Garrett: We need better support for SSH host certificates

Posted Mar 27, 2023 12:02 UTC (Mon) by ballombe (subscriber, #9523) [Link] (8 responses)

The current trend is to provision system using automated configurations system like kubernetes where configuration
are stored in a GIT repository. So the pressure is great to store the secret key in the GIT repo so that the configuration system can install it. Matthew correctly note that there are no simple, robust alternatives provided by ssh.

The simplest alternative (generating a new key each time) leads to teaching users to ignore the ssh warning, which is arguably worse.

As for your main point, github belongs to Microsoft now, so they have to follow their security posture, what ever it is.

Garrett: We need better support for SSH host certificates

Posted Mar 27, 2023 16:00 UTC (Mon) by walters (subscriber, #7396) [Link]

"gitops" is not specific to Kubernetes. Also, Kubernetes has a first-class "secret" object type and any gitops solution particularly targeted for Kubernetes is going to integrate with it; e.g. https://argo-cd.readthedocs.io/en/stable/operator-manual/secret-management/

Garrett: We need better support for SSH host certificates

Posted Mar 27, 2023 21:09 UTC (Mon) by Vipketsh (guest, #134480) [Link] (6 responses)

> teaching users to ignore the ssh warning

These sentences sound great and seemingly solve the problem, but in reality they just pass the responsibility around. I've never seen any explanation of what to actually *do* when you get the warning. It's easy to say "the user needs to check", but check what exactly ?

If by some miracle the key/fingerprint is found to be incorrect (let's say it's evidence of a man-in-the-middle) what is the user to do ? Clearly the user wanted to use the service so just give up ? Try to contact someone ? Who exactly ? We all know that there is never anyone to contact and especially anyone who would give a reasonable answer in reasonable time.

Garrett: We need better support for SSH host certificates

Posted Mar 28, 2023 1:22 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (5 responses)

If the key doesn't match, there are basically two possibilities:

1. The key got changed for a legitimate reason. The people who run the service will be very aware of the warning, and so they will not do this if they can avoid it. If it's unavoidable, then they will (or at least, should) proactively put up warnings on their website, which you can consult over HTTPS.
2. The key got changed because someone is MitM'ing you. Then you need to go convince your ISP, IT department, and/or government to stop MitM'ing you.

As I mentioned in another comment chain, (1) is a solved problem for HTTPS keys, and from a technical perspective, it would be relatively straightforward to adapt that solution to the SSH use case, but (apparently) some people disagree with doing that. OTOH, (2) will never be possible to solve with technology. The tech can tell you that it is happening, but it cannot tell you what to do about it, because this is a social problem, not a technical problem.

Garrett: We need better support for SSH host certificates

Posted Mar 28, 2023 1:33 UTC (Tue) by NYKevin (subscriber, #129325) [Link]

> because this is a social problem, not a technical problem.

To further expound on this, because I was a little too terse: While it is likely possible to circumvent an MitM attack through the clever use of tunneling, VPNs, Tor, etc., the fundamental issue is that you have been given an insecure internet connection. Someone decided to give you that insecure internet connection. That person is the problem. Remove them from a position of authority over your internet connection, and the problem goes away.

Garrett: We need better support for SSH host certificates

Posted Mar 28, 2023 6:47 UTC (Tue) by zdzichu (subscriber, #17118) [Link]

The 2) is exactly what happened at my place of work last week. The first developer to notice fingerprint mismatch message made a screenshot, alerted security and platform guys, then disconnected his computer and waited for further instructions.

The platform guys checked the situation, basically by going to Github's blog and reading about the change. Then provided company-wide heads-up on Slack. With guidelines how to remove old keys and check the fingerprints of new ones.

I strongly commend the first developer, his behaviour was professional and an example for others.

Garrett: We need better support for SSH host certificates

Posted Mar 28, 2023 9:39 UTC (Tue) by Vipketsh (guest, #134480) [Link] (2 responses)

You don't explain how one is supposed to differentiate between the two cases and when done what actions one is to take to get it resolved. Most people don't even have any idea that there are these two cases to begin with, not to mention that any site that is not as high profile as github often doesn't post such details anywhere. Those who put in the effort and are able to differentiate are still pretty much out of luck, because:

> 1. The key got changed for a legitimate reason.

So there is no problem and the warning is useless and the right thing to do is just bypass it.

> 2. The key got changed because someone is MitM'ing you.

Great, so as per your assessment this can be:

> ISP

Easy! I'll get the CEO replaced tomorrow. How hard could this ever be ?

> IT department

Support desks are known to be very responsive, to the point, give detailed explanations, and fix things immediately. Especially when it comes to security. A support desk brick walling people ? Never heard of it! Very easy to solve, clearly.

> government

No problem! I'll just get a new government installed tomorrow, make the appropriate law changes, issue the right directives and problem solved. It would take me a whole day ? I must be slow.

In summary: it's great that you know you are the target of a MitM attack, but reasonably you have two choices: (i) disconnect from the internet and go live in a cave or (ii) just suck it up and hope for the best. Option (i) isn't reasonable in today's world so that leaves one with (ii) and blindly ignoring warnings.

I'm not saying that this is problem is immaterial to talk about or to try to solve, but it is also quite disingenuous to waive it away with "it's [the user's] social problem" and blame users when they end up ignoring warnings. If anything, the social problem is more on the service providers' side who often don't inform users of problems/changes, put those explanations in places you have to hunt for it and/or try as hard as they can to build a wall between them and those "pesky lusers".

Garrett: We need better support for SSH host certificates

Posted Mar 28, 2023 15:59 UTC (Tue) by NYKevin (subscriber, #129325) [Link]

> You don't explain how one is supposed to differentiate between the two cases and when done what actions one is to take to get it resolved.

Yes I did. I told you to go read the organization's website, which would have worked in the GitHub case.

> In summary: it's great that you know you are the target of a MitM attack, but reasonably you have two choices: (i) disconnect from the internet and go live in a cave or (ii) just suck it up and hope for the best. Option (i) isn't reasonable in today's world so that leaves one with (ii) and blindly ignoring warnings.

There is also (iii) stop trying to use the service and go do something else instead, or (iv) use it and accept that you don't have any security guarantees.

> blame users when they end up ignoring warnings.

Nowhere in my comment did I blame the user. Please do not put words in my mouth. My position is that this is not a problem the technology is capable of solving. That doesn't make it the user's fault.

Garrett: We need better support for SSH host certificates

Posted Mar 28, 2023 17:49 UTC (Tue) by geert (subscriber, #98403) [Link]

> > IT department
>
> Support desks are known to be very responsive, to the point, give detailed explanations, and fix things immediately. Especially when it comes to security. A support desk brick walling people ? Never heard of it! Very easy to solve, clearly.

You are accessing github at work, so clearly this must be related to your work. So you are interacting with github projects to create products for your customers, or for use in your internal infrastructure. I guess at least someone at a higher level in your company must care if your product or internal infrastructure would become compromised?