2 ms·

Re SSH: sure, it can happen, but in practice I'd rate this pretty low with most SSH users... (1) You need new host which hasn't been TOFU'd yet, and you need i

by theamk 2y ago

Re SSH: sure, it can happen, but in practice I'd rate this pretty low with most SSH users... (1) You need new host which hasn't been TOFU'd yet, and you need it to be exposed to internet with no VPN/mesh inbetween. (2) You need password-based authentication _or_ agent forwarding, otherwise you won't be able to intercept traffic (with key-based auth, you can pretend to be the server, but that won't likely to last long). While I would not say that everyone uses key-based ssh, they should! It's an easy way to significantly increase your SSH security level. As for HTTPs MITM, I don't see how this applies. They had to intercept traffic next to a server to be able to issue certificate - and I am pretty sure no one runs servers from the untrusted coffee shop connection! And you already have access to the server's datacenter, then there is no need to exploit public WiFi, you can intercept the server's traffic directly.

tjoff 2y ago
2: key based ssh won't really help and isn't the magic bullet people seem to believe. Especially nonencrypted ssh keys which is what the majority uses.
- theamk 2y ago
  sure it is, as long as you don't have agent forwarding 1. The ssh connection is intercepted, malicious server lets accepts arbitrary user's public key 2. Malicious server tries to connect to real server and fails - original pubkey authentication was channel-bound and cannot be reused 3. Malicious server now has to pretend to be the real server without knowing what the real server looks like. User immediately detects the shell prompt is different, the hostname is wrong, all the files are missing, etc... and disconnects. (You can make some sort of contrived situation, like you only ssh'd to restart service, _and_ you used "sudo" with password _and_ you used ssh command so you didn't see the prompt _and_ this was the first command you did on your new computer... but this seems pretty unlikely) And encrypted vs non-encrypted keys seems completely unrelated to connection interception attacks - who cares how the keys are stored on the computer? It's all the same on the wire.
  - tjoff 2y ago
    You assume that the server already knows the key though? The assumption was that it is the first time they connect. Which if so would mean that the key was configured out of band, but if we add that possibility you can do the TOFU out of band as well. Yes, it is more common to transfer keys out of band - but it is getting a bit contrived.
tsimionescu 2y ago
The HTTPS MITM case doesn't need to intercept close to the server, it just needs to know that Victim is trying to talk to a particular server. Then, they obtain a forged certificate, and use the same mechanism shown here to intercept the TLS ClientHello and pretend to be the TLS server, with the legitimate certificate. The reason this works is because in a targetted attack, it's much less likely that the improperly issued certificate would become public and (1) be revoked, and (2) cause problems for the CA that issued it.

by theamk 2y ago

tjoff 2y ago

2: key based ssh won't really help and isn't the magic bullet people seem to believe. Especially nonencrypted ssh keys which is what the majority uses.

theamk 2y ago
sure it is, as long as you don't have agent forwarding 1. The ssh connection is intercepted, malicious server lets accepts arbitrary user's public key 2. Malicious server tries to connect to real server and fails - original pubkey authentication was channel-bound and cannot be reused 3. Malicious server now has to pretend to be the real server without knowing what the real server looks like. User immediately detects the shell prompt is different, the hostname is wrong, all the files are missing, etc... and disconnects. (You can make some sort of contrived situation, like you only ssh'd to restart service, _and_ you used "sudo" with password _and_ you used ssh command so you didn't see the prompt _and_ this was the first command you did on your new computer... but this seems pretty unlikely) And encrypted vs non-encrypted keys seems completely unrelated to connection interception attacks - who cares how the keys are stored on the computer? It's all the same on the wire.
- tjoff 2y ago
  You assume that the server already knows the key though? The assumption was that it is the first time they connect. Which if so would mean that the key was configured out of band, but if we add that possibility you can do the TOFU out of band as well. Yes, it is more common to transfer keys out of band - but it is getting a bit contrived.

tsimionescu 2y ago

The HTTPS MITM case doesn't need to intercept close to the server, it just needs to know that Victim is trying to talk to a particular server. Then, they obtain a forged certificate, and use the same mechanism shown here to intercept the TLS ClientHello and pretend to be the TLS server, with the legitimate certificate. The reason this works is because in a targetted attack, it's much less likely that the improperly issued certificate would become public and (1) be revoked, and (2) cause problems for the CA that issued it.