4 ms·

Nobody ever mentions that TOFU requires the attacker to commit to the attack before they know whether you know the fingerprint. Somebody could set up on that pu

Nobody ever mentions that TOFU requires the attacker to commit to the attack before they know whether you know the fingerprint. Somebody could set up on that public wifi and intercept ssh, but they'd be detected as soon as anybody with a previously known key tries to connect. They can't wait for you to connect to an unknown server, because they don't know what you don't know. If you're not sure about the network, you can connect to a known host first to check for funny business. Or turn on the option for ascii art keys.

c7DJTLrn 3y ago
Good point. If we're being imaginative, there's various side channels an attacker could use to carefully target their attack, such as seeing a new MAC or DHCP lease on the local network.
- deleted 3y ago
  [deleted]
- xg15 3y ago
  True. Also depends on what the target is. I.e., if the attacker wants to impersonate machines that are only avaliable on the local network, then it's probably reasonable to conclude that a machine which was never seen on that LAN before also hasn't yet connected to the impersonated host. However, that isn't true for "public" SSH endpoints, such as github, gitlab etc - e.g. if the attacker is impersonating the wifi if the nearest Starbucks to snoop on all the hipster solo-devs there, he'll probably be unable to impersonate github, because even people who use that wifi for the first time have probably connected to github before, on a different network.
SoftTalker 3y ago
> they'd be detected as soon as anybody with a previously known key tries to connect Would they? Or would the person just delete the old key from their ~/.ssh/known_hosts and accept the new one?
- tedunangst 3y ago
  If you're deleting keys from known_hosts, you're not trusting on first use.
  - mjochim 3y ago
    That is correct. And still, many, many devs and admins would do exactly that. Which is why in many, many cases, Tofu really isn't Tofu but "trust whatever." When designing or evaluating security, one should not ignore that this is a part of reality.
    - arp242 3y ago
      That's a bit of a different issue from the "Let’s say you’re on a fresh machine" that this article is about. I agree that "automatic trust on first use" is "good enough" for most cases and people (especially with sshfp records), and to be honest I think the warning you get once that fails is strong enough: % git clone git@github.com:madmurphy/libconfini.git Cloning into 'libconfini'... @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ED25519 key sent by the remote host is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU. Please contact your system administrator. Add correct host key in /home/martin/.ssh/known_hosts to get rid of this message. Offending ED25519 key in /home/martin/.ssh/known_hosts:118 Host key for github.com has changed and you have requested strict checking. Host key verification failed. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. It's a strong warning, with a manual fix that's more than "just press ok" (probably intentionally), and if you choose to ignore that then that's your problem. I'm not really sure what could be done better? A centralized https-like system comes with its own downsides. (The only complaint is that last "Please make sure you have the correct access rights and the repository exists" line, which is from git and not ssh, and a tad confusing; maybe it's possible for git to do better here?)

c7DJTLrn 3y ago

Good point. If we're being imaginative, there's various side channels an attacker could use to carefully target their attack, such as seeing a new MAC or DHCP lease on the local network.

deleted 3y ago
[deleted]
xg15 3y ago
True. Also depends on what the target is. I.e., if the attacker wants to impersonate machines that are only avaliable on the local network, then it's probably reasonable to conclude that a machine which was never seen on that LAN before also hasn't yet connected to the impersonated host. However, that isn't true for "public" SSH endpoints, such as github, gitlab etc - e.g. if the attacker is impersonating the wifi if the nearest Starbucks to snoop on all the hipster solo-devs there, he'll probably be unable to impersonate github, because even people who use that wifi for the first time have probably connected to github before, on a different network.

SoftTalker 3y ago

> they'd be detected as soon as anybody with a previously known key tries to connect Would they? Or would the person just delete the old key from their ~/.ssh/known_hosts and accept the new one?

tedunangst 3y ago
If you're deleting keys from known_hosts, you're not trusting on first use.
- mjochim 3y ago
  That is correct. And still, many, many devs and admins would do exactly that. Which is why in many, many cases, Tofu really isn't Tofu but "trust whatever." When designing or evaluating security, one should not ignore that this is a part of reality.
  - arp242 3y ago
    That's a bit of a different issue from the "Let’s say you’re on a fresh machine" that this article is about. I agree that "automatic trust on first use" is "good enough" for most cases and people (especially with sshfp records), and to be honest I think the warning you get once that fails is strong enough: % git clone git@github.com:madmurphy/libconfini.git Cloning into 'libconfini'... @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ED25519 key sent by the remote host is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU. Please contact your system administrator. Add correct host key in /home/martin/.ssh/known_hosts to get rid of this message. Offending ED25519 key in /home/martin/.ssh/known_hosts:118 Host key for github.com has changed and you have requested strict checking. Host key verification failed. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. It's a strong warning, with a manual fix that's more than "just press ok" (probably intentionally), and if you choose to ignore that then that's your problem. I'm not really sure what could be done better? A centralized https-like system comes with its own downsides. (The only complaint is that last "Please make sure you have the correct access rights and the repository exists" line, which is from git and not ssh, and a tad confusing; maybe it's possible for git to do better here?)