Preferences

>And I would argue that MITMing communications is a lot hard for (non-nation state) attackers than compromising a host, so trust compromise is a questionable worry.

By that logic, we don't really need certificates, just TOFU.


throw0101d
> By that logic, we don't really need certificates, just TOFU.

It works fairly well for SSH, but that tends to be a more technical audience. But doing a "Always trust" or "Always accept" are valid options in many cases (often for internal apps).

tptacek
It does not work well for SSH. We just don't care about how badly it works.
throw0101d
> It does not work well for SSH. We just don't care about how badly it works.

How "should" it work? Is there a known-better way?

tptacek
Yes: SSH certificates. (They're unrelated to X509 certificates and the WebPKI).
throw0101d
> Yes: SSH certificates. (They're unrelated to X509 certificates and the WebPKI).

I am aware of them.

As someone in the academic sphere, with researchers SSHing into (e.g.) HPC clusters, this solves nothing for me from the perspective of clients trusting servers. Perhaps it's useful in a corporate environment where the deployment/MDM can place the CA in the appropriate place, but not with BYOD.

Issuing CAs to users, especially if they expire is another thing. From a UX perspective, we can tie password credentials to things like on-site Wifi and web site access (e.g., support wiki).

So SSH certs certainly have use-cases, and I'm happy they work for people, but TOFU is still the most useful in the waters I swim in.

This item has no comments currently.