Hacker News Reader

Comment by ptx | Hacker News Reader

Surely the attacker can serve up an SSH server implementation that forwards the connection to the intended server while recording and/or modifying the decrypted traffic as desired? To the user everything would appear as normal (expect perhaps for some additional latency) but their data would be exposed to the attacker.

If there were no way to perform a MITM attack because you would notice that you were connected to the wrong server, the whole system of keys and fingerprints would be pointless. So would the CA system for HTTPS.

View on HN

> Surely the attacker can serve up an SSH server implementation that forwards the connection to the intended server while recording and/or modifying the decrypted traffic as desired? To the user everything would appear as normal (expect perhaps for some additional latency) but their data would be exposed to the attacker

The attacker can’t do this because the attacker does not have your private key. If the attacker proxies your authentication to the remote server, they’ll only be back to square one as the connection is now encrypted with keys the attacker does not hold.

This is only possible if you use password auth.

> If there were no way to perform a MITM attack because you would notice that you were connected to the wrong server, the whole system of keys and fingerprints would be pointless. So would the CA system for HTTPS.

It’s much easier for an attacker to create a malicious copy of a website they have access to than a server they don’t.

The phishing opportunities offered by a SSH mitm attack like this are rather limited.

> This is only possible if you use password auth.

It's not possible with password auth, either.

If you check the server's SSH fingerprint on first connection, you're safe from man-in-the-middle attacks, regardless of how you authenticate the user. If you fail to check the server's fingerprint (the way most people use SSH), then you haven't verified the identity of the server, and again this is regardless of how you authenticate the user.

There are other advantages to using a public key to authenticate the user, though. [0]

[0] https://security.stackexchange.com/a/69408

> It's not possible with password auth, either

It is, if you screw up with TOFU.

> If you fail to check the server's fingerprint (the way most people use SSH), then you haven't verified the identity of the server, and again this is regardless of how you authenticate the user.

This has different ramifications depending on how you authenticate.

> It is, if you screw up with TOFU.

If you simply forget to check the fingerprint, you've got a problem, yes, and this is a risk if it's expected to be done manually. Most users simply can't be bothered, despite that their SSH security depends on it.

As I said though, if you screw up the TOFU check, it's game-over either way: you've failed to verify the identity of the server. If you perform the TOFU check properly, then you have verified the identity of the server. Again, this is regardless of whether you use a password or a public key to authenticate the user.

> This has different ramifications depending on how you authenticate.

Right. With public key authentication, the server is never sent the user's secret (their private key), unlike with password authentication, where the server is entrusted with the user's secret (their password).

This could of course be significant if the attacker is able to capture the user's password, perhaps for the purposes of setting up a man-in-the-middle attack, but I think it's reasonable to treat it as game-over if an attacker has tricked a user into connecting to a machine under the attacker's control. HTTPS works this way; we should apply the same thinking to SSH.

> The attacker can’t perform an useful MITM attack on the connection no matter what key you accept from the server ... The attacker can’t do this because the attacker does not have your private key.

Why does the attacker need my private key? If he has his own private key and I accept it then he can successfully perform a MITM attack and proxy the connection to the real server.

If not, then what is the purpose of key fingerprints and the web CA system?

There is no need to involve "malicious copies" of servers or sites - you just have to intercept the data in transit between the user and the real server. If the client connects to the attacker (accepting his key) and the attacker connect to the real server, both client and server believe they are talking to each other but they are actually both talking to the attacker, who passes the data on. For HTTPS there is a handy tool[1] available to do this. If there isn't already one for SSH, the same principle still applies.

[1] https://mitmproxy.org/

> Why does the attacker need my private key?

To authenticate as the user on the target server.

> If he has his own private key and I accept it then he can successfully perform a MITM attack and proxy the connection to the real server.

That's not the case.

If you accept the public key offered by the attacker's machine-in-the-middle, then half the attacker's work is done, as they've tricked you into connecting to their machine. The other half of their work still remains though: they need to connect to the target server, impersonating the user.

They can't do this, as they don't have your private key. It doesn't do them any good to try to generate their own keypair, as it won't be recognised by the server. (Roughly equivalent to guessing at a password.)

I'm not sure if I've been very clear. There are plenty of explanations of public key crypto out there better than I can provide here.

It's a major advantage of using public keys to authenticate users, rather than passwords. (Servers are always authenticated using a public key.) If we were using passwords, then in the situation we've described above, it would be possible for the attacker to connect to the target server, impersonating us, and enabling them to set up a man-in-the-middle. The attacker just needs to capture our password when we send it to them. Of course, as they now have our password, they might do plenty else besides.

> what is the purpose of key fingerprints and the web CA system?

It's to ensure the target machine really is the expected target machine.

As you say, the web uses certificate authorities. SSH supports a similar approach, but the 'conventional' SSH solution is to manually check the server's fingerprint (which has the effect of checking the server's public key).

> For HTTPS there is a handy tool[1] available to do this. If there isn't already one for SSH, the same principle still applies.

That's just a web proxy, there are many of these available. If such a proxy is used maliciously to attempt to intercept an HTTPS connection, the connection will fail the browser's certificate-authority check, and will be terminated. (At the very least, the user will be shown a scary warning popup, but sensible modern browsers may just refuse the connection entirely, as users tend to unthinkingly click through such popups.)

These proxies can only work with HTTPS if the (self-signed) certificate used by the proxy, is added to the browser's list of trusted certificates. [0]

[0] https://docs.mitmproxy.org/stable/overview-getting-started/

Ah, good point, thanks. I misread the first sentence of the comment I was responding to as being about the server's public key, so I was assuming password authentication.

With pubkey authentication (or rarely-seen-in-practice authentication with client SSL certs on the web) the attacker couldn't impersonate the client.

Right, but it's still pretty disastrous if the attacker succeeds in tricking you into connecting to their machine, so you still need to verify the server's fingerprint.

Reply on news.ycombinator.com