4 ms·

I feel like this is unnecessarily reductive. The initial handshake is always fraught with security problems. I struggle to see a scenario in which a bad actor i

by kqr 1y ago

I feel like this is unnecessarily reductive. The initial handshake is always fraught with security problems. I struggle to see a scenario in which a bad actor is able to give me the address of a bad machine, yet not be able to trick me into their host key being the correct one. I would definitely however spend effort into verifying a host key that changes unexpectedly.

jrochkind1 1y ago
I'll be honest, I have never spent effort on a host key that had changed unexpectedly, and at least a few have.
- kragen 1y ago
  I've often called people on the phone and stuff. It depends somewhat on what's at stake. Authenticating users with SSH passwords puts much more at stake than using public keys, since an attacker who can get you to send your unencrypted password to a malicious server once can steal your account; deploying PAKE algorithms (successors to SRP, see https://eprint.iacr.org/2021/1492.pdf https://eprint.iacr.org/2021/1492.pdf) could mitigate that, but I don't think any shipped SSH version has ever supported a PAKE algorithm.
amelius 1y ago
We need a new protocol, where installing the OS of a new machine automatically installs a trusted key from an inserted USB drive, so that the machine automatically becomes part of the "enclave". Or something like that.
- organsnyder 1y ago
  This is common in corporate environments.
- MaxMatti 1y ago
  The paper does mention that you can have your ssh keys signed by a ca, so in a company the it staff could configure everybodys os to only trust ssh keys signed by the organization.
  - otabdeveloper4 1y ago
    > you can have your ssh keys signed by a ca Good idea. That way when your CA private key leaks (the key which we never ever rotate, of course) the bad guys can compromise the whole fleet and not just one server. Bonus points if the same CA is also used for authenticating users.
    - waste_monk 1y ago
      >That way when your CA private key leaks (the key which we never ever rotate, of course) As with X.509, any serious usage will involve a hardware security module, so that compromise of the CA host does not allow the key to be leaked. You'd still have a very bad day, but it can be mitigated. I do think it's a fairly significant flaw that SSH CA doesn't support intermediate CA's (or at least didn't last time I looked into it) to enable an offline root CA. >Bonus points if the same CA is also used for authenticating users. The SSH CA mechanism can be used for both Host and User auth, yes. Keeping in mind, in a real use case this would be tied to something like active directory / LDAP, so you can automate issuance of ssh keys to users and hosts. Systems configured to trust the SSH CA can trust that the user logging in is who they say they are because the principal has already been authenticated and vouched for by the identity provider, no more manually managing known_hosts and authorized_keys, or having to deal with Trust On First Use or host key changed errors. You can also set the CA's endorsement of the issued keys to fairly short lifetimes, so you can simplify your keymat lifecycle management a great deal - no worrying about old keys lying around forever if the CA only issues them as valid for an hour / day / etc. . Overall I think you still come out ahead on security.
      - deleted 1y ago
        [deleted]
- thesuitonym 1y ago
  You are under no obligation to use the generated, self-signed key. Most people do because it's "good enough".
kragen 1y ago
They might be able to spoof your DNS, for example if you're using their Wi-Fi, so you get the wrong IP address for the right hostname, but not your mail server's SSL. You could pass the host key fingerprint across an existing secure connection, such as in email or with ssh to a host that you already have the fingerprint of.
- kqr 1y ago
  Sure, but they'd have to do this on the first connection attempt. Rarely do I try to connect to new servers when I'm not using a trusted connection – among other things for this very reason.
- whatevaa 1y ago
  5 dollar wrench xckd applies here.
  - kragen 1y ago
    No, it really doesn't, as in most cases where people invoke it.
  - integralid 1y ago
    It does not. DNS attacks happen. It won't be used by APT on you or me, but may be used as an escalation mechanism in a company, for example. It's also something a hacked router could do, but I never heard of it happening, to be fair. I was actually personally a victim of such (unsuccessful) attack in the tor network. SSH login to my hidden service complained about a wrong fingerprint. The same happened when I tried again. After tor restart, problem disappeared. I assume this was an attempt at SSH mitm by one of exit nodes?
    - kragen 1y ago
      That's possible. I've also had this happen with Wi-Fi captive portals; I assume redirecting all the port 22 traffic to port 22 on the router was an unintentional side effect of redirecting all the port 80 traffic to port 80 on the router.
dspillett 1y ago
> I struggle to see a scenario in which a bad actor is able to give me the address of a bad machine, yet not be able to trick me into their host key being the correct one. If you aren't bothering to verify then they do not need to trick you at all. In DayJob we have a lot of clients send feeds and collect automated exports via SFTP, and a few to whom we operate the other way (us pulling data via SFTP or pushing it to their endpoint). HTTPS based APIs are very common and becoming more so, but SFTP is still big in this area (we offer some HTTPS APIs, few use them instead of SFTP). One possible exploit route, for a malicious actor playing a long and targetted game, that could affect us: 1. Attacker somehow poisons our DNS, or that of a specific prospective client of ours, sending traffic for sftp.ourname.tld to their server, and has access to our mail. 2. Initially they just forward traffic so key verification works for existing users. They monitor for some time to record host addresses that already access the server, so when they start intervening they can keep just forwarding connections from those addresses, so those users see no warnings (and are unaffected by the hack). 3. When they do start to intercept connections from hosts not already on the list make above instead of forwarding everything, existing users are unaffected¹ but new users coming in from entirely different addresses now go to their server and if they are not verifying the key will happily send information through it², authenticating with the initial user+pass we sent or PKI using the public key they sent, with the malicious server connecting through to ours to complete the transfers. 4. Now wait and collect data as no one realises there is a MitM, and later use any PII or other valuable information for ransom/extortion purposes. Of course there are ways to mitigate this attack route. For one: source address whitelisting, supported by OpenSSH's key based auth as the acceptable source list can be included with the public key so only specific sources can use that key for auth. But they client would have to make effort to do this, and if they aren't going to make the effort to verify the host key then they aren't going to make other efforts either. We do have some clients who verify the host properly and/or give us source addresses to limit connections to when they provide a public key, we work with financial institutions who are appropriately paranoid about their data and the data of their customers, some even use PGP for data in transit (and in case it is ever stored where it shouldn't be) for an extra level of paranoia. But most do none of this. Most utterly ignore our strong suggestion that they use keys, or change passwords in case of email breach, instead using the password we mail them before first connection for eternity. -------- [1] none of our clients are likely to be sending files from dynamic source addresses, at most the source might move around a v4/24 or v6/64, currently I don't think all of them connect from a single IPv4 address, I've had one recently let us know (months in advance) that their source address will be changing. [2] it can connect to us and send the data
zenmac 1y ago
Server should publish their key fingerprint to at least the authorized personal of the group. So people know if the server they are connecting to is actually that server.
otabdeveloper4 1y ago
> ...a host key that changes unexpectedly. Literally happens every single damn day and literally nobody on the face of this earth ever gives a shit. Host keys are the stupidest idea in the history of computer so-called "security".
- BenjiWiebe 1y ago
  Why are yours changing every day? If they always did that, then yes it would be a stupid idea. But they don't change on their own, or for no reason, so it isn't a stupid idea. Mine change maybe once every couple of years, if I do a full reinstall without copying over the old host key. And then I know exactly why it changed.
  - otabdeveloper4 1y ago
    > Why are yours changing every day? Nobody knows how the hell the host keys are generated in the first place. Don't worry about it. > And then I know exactly why it changed. Really? What is a "full" reinstall as opposed to a "non-full" reinstall, and how much exactly reinstall do I need for my host keys to change?
    - rcxdude 1y ago
      the only time the host keys should change is if you a) delete them (either by wiping the whole machine or just deleting the files), or b) explicitly regenerate them. If they're changing for any other reason you're doing something weird.
      - BenjiWiebe 1y ago
        Or they're getting MITM'd repeatedly by multiple different attackers...
        otabdeveloper4 1y ago
        Probably not. MITM pretty much never happens in the real world.
chasil 1y ago
My corporate SFTP server that became mandated to use several years ago presented multiple keys, apparently because it was on DNS round robin. My attempts to convince them to use the same key came to naught, so instead I use one of the IP addresses. I could alternately erase the known hosts entry on each transfer. That would probably have been preferable. I also got a shell on it when I attempted ssh, so you can guess the care that is taken with it.

by kqr 1y ago

jrochkind1 1y ago

I'll be honest, I have never spent effort on a host key that had changed unexpectedly, and at least a few have.

kragen 1y ago
I've often called people on the phone and stuff. It depends somewhat on what's at stake. Authenticating users with SSH passwords puts much more at stake than using public keys, since an attacker who can get you to send your unencrypted password to a malicious server once can steal your account; deploying PAKE algorithms (successors to SRP, see https://eprint.iacr.org/2021/1492.pdf https://eprint.iacr.org/2021/1492.pdf) could mitigate that, but I don't think any shipped SSH version has ever supported a PAKE algorithm.

amelius 1y ago

We need a new protocol, where installing the OS of a new machine automatically installs a trusted key from an inserted USB drive, so that the machine automatically becomes part of the "enclave". Or something like that.

organsnyder 1y ago
This is common in corporate environments.
MaxMatti 1y ago
The paper does mention that you can have your ssh keys signed by a ca, so in a company the it staff could configure everybodys os to only trust ssh keys signed by the organization.
- otabdeveloper4 1y ago
  > you can have your ssh keys signed by a ca Good idea. That way when your CA private key leaks (the key which we never ever rotate, of course) the bad guys can compromise the whole fleet and not just one server. Bonus points if the same CA is also used for authenticating users.
  - waste_monk 1y ago
    >That way when your CA private key leaks (the key which we never ever rotate, of course) As with X.509, any serious usage will involve a hardware security module, so that compromise of the CA host does not allow the key to be leaked. You'd still have a very bad day, but it can be mitigated. I do think it's a fairly significant flaw that SSH CA doesn't support intermediate CA's (or at least didn't last time I looked into it) to enable an offline root CA. >Bonus points if the same CA is also used for authenticating users. The SSH CA mechanism can be used for both Host and User auth, yes. Keeping in mind, in a real use case this would be tied to something like active directory / LDAP, so you can automate issuance of ssh keys to users and hosts. Systems configured to trust the SSH CA can trust that the user logging in is who they say they are because the principal has already been authenticated and vouched for by the identity provider, no more manually managing known_hosts and authorized_keys, or having to deal with Trust On First Use or host key changed errors. You can also set the CA's endorsement of the issued keys to fairly short lifetimes, so you can simplify your keymat lifecycle management a great deal - no worrying about old keys lying around forever if the CA only issues them as valid for an hour / day / etc. . Overall I think you still come out ahead on security.
    - deleted 1y ago
      [deleted]
thesuitonym 1y ago
You are under no obligation to use the generated, self-signed key. Most people do because it's "good enough".

kragen 1y ago

They might be able to spoof your DNS, for example if you're using their Wi-Fi, so you get the wrong IP address for the right hostname, but not your mail server's SSL. You could pass the host key fingerprint across an existing secure connection, such as in email or with ssh to a host that you already have the fingerprint of.

kqr 1y ago
Sure, but they'd have to do this on the first connection attempt. Rarely do I try to connect to new servers when I'm not using a trusted connection – among other things for this very reason.
whatevaa 1y ago
5 dollar wrench xckd applies here.
- kragen 1y ago
  No, it really doesn't, as in most cases where people invoke it.
- integralid 1y ago
  It does not. DNS attacks happen. It won't be used by APT on you or me, but may be used as an escalation mechanism in a company, for example. It's also something a hacked router could do, but I never heard of it happening, to be fair. I was actually personally a victim of such (unsuccessful) attack in the tor network. SSH login to my hidden service complained about a wrong fingerprint. The same happened when I tried again. After tor restart, problem disappeared. I assume this was an attempt at SSH mitm by one of exit nodes?
  - kragen 1y ago
    That's possible. I've also had this happen with Wi-Fi captive portals; I assume redirecting all the port 22 traffic to port 22 on the router was an unintentional side effect of redirecting all the port 80 traffic to port 80 on the router.

dspillett 1y ago

> I struggle to see a scenario in which a bad actor is able to give me the address of a bad machine, yet not be able to trick me into their host key being the correct one. If you aren't bothering to verify then they do not need to trick you at all. In DayJob we have a lot of clients send feeds and collect automated exports via SFTP, and a few to whom we operate the other way (us pulling data via SFTP or pushing it to their endpoint). HTTPS based APIs are very common and becoming more so, but SFTP is still big in this area (we offer some HTTPS APIs, few use them instead of SFTP). One possible exploit route, for a malicious actor playing a long and targetted game, that could affect us: 1. Attacker somehow poisons our DNS, or that of a specific prospective client of ours, sending traffic for sftp.ourname.tld to their server, and has access to our mail. 2. Initially they just forward traffic so key verification works for existing users. They monitor for some time to record host addresses that already access the server, so when they start intervening they can keep just forwarding connections from those addresses, so those users see no warnings (and are unaffected by the hack). 3. When they do start to intercept connections from hosts not already on the list make above instead of forwarding everything, existing users are unaffected¹ but new users coming in from entirely different addresses now go to their server and if they are not verifying the key will happily send information through it², authenticating with the initial user+pass we sent or PKI using the public key they sent, with the malicious server connecting through to ours to complete the transfers. 4. Now wait and collect data as no one realises there is a MitM, and later use any PII or other valuable information for ransom/extortion purposes. Of course there are ways to mitigate this attack route. For one: source address whitelisting, supported by OpenSSH's key based auth as the acceptable source list can be included with the public key so only specific sources can use that key for auth. But they client would have to make effort to do this, and if they aren't going to make the effort to verify the host key then they aren't going to make other efforts either. We do have some clients who verify the host properly and/or give us source addresses to limit connections to when they provide a public key, we work with financial institutions who are appropriately paranoid about their data and the data of their customers, some even use PGP for data in transit (and in case it is ever stored where it shouldn't be) for an extra level of paranoia. But most do none of this. Most utterly ignore our strong suggestion that they use keys, or change passwords in case of email breach, instead using the password we mail them before first connection for eternity. -------- [1] none of our clients are likely to be sending files from dynamic source addresses, at most the source might move around a v4/24 or v6/64, currently I don't think all of them connect from a single IPv4 address, I've had one recently let us know (months in advance) that their source address will be changing. [2] it can connect to us and send the data

zenmac 1y ago

Server should publish their key fingerprint to at least the authorized personal of the group. So people know if the server they are connecting to is actually that server.

otabdeveloper4 1y ago

> ...a host key that changes unexpectedly. Literally happens every single damn day and literally nobody on the face of this earth ever gives a shit. Host keys are the stupidest idea in the history of computer so-called "security".

BenjiWiebe 1y ago
Why are yours changing every day? If they always did that, then yes it would be a stupid idea. But they don't change on their own, or for no reason, so it isn't a stupid idea. Mine change maybe once every couple of years, if I do a full reinstall without copying over the old host key. And then I know exactly why it changed.
- otabdeveloper4 1y ago
  > Why are yours changing every day? Nobody knows how the hell the host keys are generated in the first place. Don't worry about it. > And then I know exactly why it changed. Really? What is a "full" reinstall as opposed to a "non-full" reinstall, and how much exactly reinstall do I need for my host keys to change?
  - rcxdude 1y ago
    the only time the host keys should change is if you a) delete them (either by wiping the whole machine or just deleting the files), or b) explicitly regenerate them. If they're changing for any other reason you're doing something weird.
    - BenjiWiebe 1y ago
      Or they're getting MITM'd repeatedly by multiple different attackers...
      - otabdeveloper4 1y ago
        Probably not. MITM pretty much never happens in the real world.

chasil 1y ago

My corporate SFTP server that became mandated to use several years ago presented multiple keys, apparently because it was on DNS round robin. My attempts to convince them to use the same key came to naught, so instead I use one of the IP addresses. I could alternately erase the known hosts entry on each transfer. That would probably have been preferable. I also got a shell on it when I attempted ssh, so you can guess the care that is taken with it.