Remix.run Logo
Remix clone Hacker News
new | show | ask | jobsGithub
▲ throw0101a 4 days ago

Okay, the key is compromised: that means they can MITM the trust relationship. But with modern algorithms you have forward security, so even if you've sniffed/captured the traffic it doesn't help.

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.

▲gruez 4 days ago | parent [-]

>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 4 days ago | parent [-]

> 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 4 days ago | parent [-]

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

▲throw0101d 4 days ago | parent [-]

> 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 4 days ago | parent [-]

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

▲throw0101d 4 days ago | parent [-]

> 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.

▲tptacek 4 days ago | parent [-]

I don't know what to tell you. The problem with TOFU is obvious: the FU. The FU happens more often than people think it does (every time you log in from a new or reprovisioned workstation) and you're vulnerable every time. I don't really care what you do for SSH (we use certificates) but this is not a workable model for TLS, where FUs are the norm.

▲throw0101d 4 days ago | parent [-]

> I don't really care what you do for SSH (we use certificates) but this is not a workable model for TLS, where FUs are the norm.

It was suggested by someone else: I commented TOFU works for SSH, but is probably not as useful for web-y stuff (except for maybe small in-house stuff).

Personally I'm somewhat sad that opportunistic encryption for the web never really took off: if folks connect on 80, redirect to 443 if you have certs 'properly' set up, but even if not do an "Upgrade" or something to move to HTTPS. Don't necessary indicate things are "secure" (with the little icon), but scramble the bits anyway: no false sense of security, but make it harder for tapping glass in bulk.