4 ms·

This is probably pretty common. When I first deployed virtualization at a previous job ~5 years ago, it took almost two years before I realized all images used

by ymse 11y ago

This is probably pretty common. When I first deployed virtualization at a previous job ~5 years ago, it took almost two years before I realized all images used the same host keys. Can someone versed in cryptography comment on whether this allows passive eavesdropping? Active MITM sure, but I thought session keys would be unique.

brians 11y ago
You are right: it allows active impersonation, but not passive eavesdropping.
- pflanze 11y ago
  > impersonation "Impersonification" of the server, you mean (inservication if that's a word). It would allow an attacker to operate a machine under their control that poses as mine. But then, for password based logins, that will actually be enough to impersonify the user as well (the attacker will create an ssh connection to the real server with the given password). But I wonder how things work with key based logins. I've ordered a server from Hetzner recently, I guess I'll just ditch it (and perhaps order a new one). BTW I haven't gotten any email notification from Hetzner about this yet.
  - snuxoll 11y ago
    Given that key based logins require signing a per-session token to verify the owner of the key is trying to connect (otherwise they would be useless since someone could just perform a replay attack) MITM'ing a key-authenticated session would allow you to perform attacks with that session, but it would not allow you to re-authenticate against that server later.
    - Buge 11y ago
      Would active MITM be possible with key login? I would think it should be impossible. If the symmetric session key is chosen by the server and encrypted with the client's public key, the attacker won't know it and cannot mess with the session. The only thing the attacker can do is completely impersonate the server. But the attacker cannot communicate with the actual server at all.
  - deleted 11y ago
    [deleted]
  - corford 11y ago
    No need to junk your server, just regenerate the affected key. Instructions are on their wiki here: http://wiki.hetzner.de/index.php/Ed25519 http://wiki.hetzner.de/index.php/Ed25519
    - pflanze 11y ago
      My point was that the issue didn't just allow a MITM to capture traffic, but also take over the machine(?). So cancelling the server and installing a new one will be the safer bet (I'm considering moving to a different company at the same time, as the IP block my old server is in seems to be the reason I can't deliver mail to Google, Hotmail and Yahoo (my own IP is all green in blacklists, but my neighbours' IPs aren't)). YMMV.
      - corford 11y ago
        I suppose it depends on your paranoia level and whether or not you were using keybased auth or passwords. If you were using keybased auth then simply regenerating the host key should be enough. Re: mail issues. We had the same problem (our IP was green but the block it was in was tainted). We solved the delivery issues by going through the various processes on: https://mail.live.com/mail/postmaster.aspx https://mail.live.com/mail/postmaster.aspx http://postmaster.google.com http://postmaster.google.com and https://postmaster.aol.com/ https://postmaster.aol.com/ [ in addition to following all the usual best practices - SPF, DMARC etc. ]
        pflanze 11y ago
        Thanks for the info about your mail. I'm using SPF and DKIM too, I don't see how DMARC would help deliverability so I haven't tried that yet. I've verified my domains (including the reverse name(s) of my server's IPs) with postmaster.google.com to no avail (and I'm not sending enough mail to get the actual tools enabled). Interesting that you think you could solve it that way, perhaps you're sending more mail, or perhaps M$/Google/AOL are interchanging info and it only helps when going through all of their tools, or perhaps you've sent enough mail that what actually helped was people marking mail as ham, or perhaps you're in a block that's tainted less. My strategy remains to try another IP block. I might also try disabling IPv6 (although IIRC it delivers to Google over IPv4?).
mmaunder 11y ago
SSH uses ephemeral diffie hellman which gives you forward secrecy, meaning that recorded sessions can't be decrypted later if the server private key is compromised. So sessions sniffed in the past can't be decrypted using the private key that was shared among VM's. So provided that all server owners immediately change their keys and no one was man-in-the-middled before Hetzner announced this, everyone should stay secure. I very much doubt anyone was MITM'd because it would be difficult and the prize for MITM'ing a Hetzner server isn't that motivating.

by ymse 11y ago

brians 11y ago

You are right: it allows active impersonation, but not passive eavesdropping.

pflanze 11y ago
> impersonation "Impersonification" of the server, you mean (inservication if that's a word). It would allow an attacker to operate a machine under their control that poses as mine. But then, for password based logins, that will actually be enough to impersonify the user as well (the attacker will create an ssh connection to the real server with the given password). But I wonder how things work with key based logins. I've ordered a server from Hetzner recently, I guess I'll just ditch it (and perhaps order a new one). BTW I haven't gotten any email notification from Hetzner about this yet.
- snuxoll 11y ago
  Given that key based logins require signing a per-session token to verify the owner of the key is trying to connect (otherwise they would be useless since someone could just perform a replay attack) MITM'ing a key-authenticated session would allow you to perform attacks with that session, but it would not allow you to re-authenticate against that server later.
  - Buge 11y ago
    Would active MITM be possible with key login? I would think it should be impossible. If the symmetric session key is chosen by the server and encrypted with the client's public key, the attacker won't know it and cannot mess with the session. The only thing the attacker can do is completely impersonate the server. But the attacker cannot communicate with the actual server at all.
- deleted 11y ago
  [deleted]
- corford 11y ago
  No need to junk your server, just regenerate the affected key. Instructions are on their wiki here: http://wiki.hetzner.de/index.php/Ed25519 http://wiki.hetzner.de/index.php/Ed25519
  - pflanze 11y ago
    My point was that the issue didn't just allow a MITM to capture traffic, but also take over the machine(?). So cancelling the server and installing a new one will be the safer bet (I'm considering moving to a different company at the same time, as the IP block my old server is in seems to be the reason I can't deliver mail to Google, Hotmail and Yahoo (my own IP is all green in blacklists, but my neighbours' IPs aren't)). YMMV.
    - corford 11y ago
      I suppose it depends on your paranoia level and whether or not you were using keybased auth or passwords. If you were using keybased auth then simply regenerating the host key should be enough. Re: mail issues. We had the same problem (our IP was green but the block it was in was tainted). We solved the delivery issues by going through the various processes on: https://mail.live.com/mail/postmaster.aspx https://mail.live.com/mail/postmaster.aspx http://postmaster.google.com http://postmaster.google.com and https://postmaster.aol.com/ https://postmaster.aol.com/ [ in addition to following all the usual best practices - SPF, DMARC etc. ]
      - pflanze 11y ago
        Thanks for the info about your mail. I'm using SPF and DKIM too, I don't see how DMARC would help deliverability so I haven't tried that yet. I've verified my domains (including the reverse name(s) of my server's IPs) with postmaster.google.com to no avail (and I'm not sending enough mail to get the actual tools enabled). Interesting that you think you could solve it that way, perhaps you're sending more mail, or perhaps M$/Google/AOL are interchanging info and it only helps when going through all of their tools, or perhaps you've sent enough mail that what actually helped was people marking mail as ham, or perhaps you're in a block that's tainted less. My strategy remains to try another IP block. I might also try disabling IPv6 (although IIRC it delivers to Google over IPv4?).

mmaunder 11y ago

SSH uses ephemeral diffie hellman which gives you forward secrecy, meaning that recorded sessions can't be decrypted later if the server private key is compromised. So sessions sniffed in the past can't be decrypted using the private key that was shared among VM's. So provided that all server owners immediately change their keys and no one was man-in-the-middled before Hetzner announced this, everyone should stay secure. I very much doubt anyone was MITM'd because it would be difficult and the prize for MITM'ing a Hetzner server isn't that motivating.