5

When connecting to a server for the first time, ssh usually requires users to check server's fingerprint and then caches the info. This is needed in order to prevent MiTM.

Is it a design flaw in SSH that a user is required to check fingerprint manually? I mean the following use-case.

There is a server. There is a client. The server provide some personalized services to authenticated users. So it is the server's responsibility to check user's credentials properly.

Server knows its fingerprint. Let's assume that the client (not ssh one, but an app built upon ssh, like a GUI client for git) is unwiling to check the fingerprint because in order to do it it should get the true fingerprint somehow, which means GUI for that has to be implemented.

The authentication protocol is that the client signs the challenge provided by the server, the server verifies it and then allows access. It feels like a design flaw: a malicious server can impersonate a user to a legitimate server by doing MiTM and proxying user's responses to the original server.

The way to fix that would be to sign not only challenge, but also server's fingerprint. (See the accepted answer for the right picture) Then the server can detect MiTM server-side. Though it doesn't protect from a malicious server being impersonated to a user.

  • 2
    This mechanism is called "Trust on First Use" (TOFU). – Sjoerd May 13 at 9:09
  • Not quite what you asked, but read up on SSH CA as it addresses this problem – paj28 May 13 at 9:24
  • 1
    @SteffenUllrich KOLANICH does propose a new scheme and is basically asking why we're all so stupid to use the current, "broken" tofu/manual-check scheme instead of what he cooked up. Not exactly a duplicate of how to find the hostkey in a trusted manner. – Luc May 13 at 10:12
  • 1
    @Luc: Oh, I've focused too much on 90% of the question and the title and did not see that the last two sentences had some proposal for change hidden which I did not expected from reading the title and the rest of the body. – Steffen Ullrich May 13 at 11:03
  • 1
    @SteffenUllrich Agreed, it's a little hidden. I initially missed it and had to edit my answer later. Might be good to edit the question. – Luc May 13 at 11:08
8

In short: it is not a design flaw. You've just had a misunderstanding of the design.

The authentication protocol is that the client signs the challenge provided by the server, the server verifies it and then allows access.

The client does not sign a challenge provided by the server. Instead the client signs a structure defined in RFC 4252 section 7 which includes as a major component the session identifier. This session identifier itself is a result of the key exchange as described in RFC 4253 section 7.2.

... a malicious server can impersonate a user to a legitimate server by doing MiTM and proxying user's responses to the original server.

Since the MITM does not have access to the clients private key it cannot create a new signature with this key. Thus it needs to find a way to make the server accept the original signature by the client. And since the signature depends on the session identifier the MITM would need to establish a SSH connection between client and MITM and another between MITM and server which both have the same session identifier.

But in the Diffie Hellman key exchange the result of the key exchange depends both on client data unknown to the server and server data unknown to the client. Since the MITM has only control over one side of each connection it cannot control the result of the key exchange and thus cannot control the session identifier.

Therefore the attack you describe will not work. The MITM cannot simply impersonate the client as long as the server properly authenticates the client. Either the authentication will fail because the signature is broken (does not match the session identifier) or it will fail because the public key is not the one expected by the server (in case MITM made up its own client key).

  • 1
    Wait so fingerprint checking is not needed if you put a public key on the server already, assuming the server either accepts hostkey authentication only or you are smart enough not to enter your password if the "server" (i.e. a mitm) unexpectedly prompts for it? – Luc May 13 at 14:59
  • 3
    @Luc I'm fairly certain that connecting to an illegitimate server is still an issue, it's just that that server won't be able to act as a proxy and connect with the correct server. So it's not a MitM really, but it's still a problem. – AndrolGenhald May 13 at 15:56
  • 3
    @Luc: A scenario where a MITM actively intercepts the connection to the original server is not possible if the client uses key based authentication. But it is still possible that some attacker impersonates a server and simply accepts your key, only he cannot use this then to impersonate you against the real server. This is actually the same with TLS, i.e. both legal and malicious TLS interception are not possible if client certificates are involved, the MITM does not have your client certificate and the server strictly checks your certificate. – Steffen Ullrich May 13 at 17:29
  • @SteffenUllrich I suggest you add the content of your Comment to your Answer. That info is vital, and I’ve not seen it presented anywhere else. – Basil Bourque Jul 12 at 22:27
5

Is it a design flaw in SSH that a user is required to check fingerprint manually?

It has pros and cons (surprise!).

Websites use a 'trusted' third party for HTTPS. We all trust the Staat Der Nederlanden, Chunghwa, Atos, and the China Financial Certification Authority to verify your connection between you and your bank, right? Because that's exactly what they're doing, and this has been known to go wrong in the past. But it's the best we got: we can't expect our moms to ring up the bank to ask their fingerprint, so we need to use these semi-trusted certificate authorities.

For SSH, it is mainly used by system administrators or other power users, so it is more reasonable to expect that they check the fingerprint, or at least understand what it is. A security-aware admin can check it, if they wish to do so (for example, I work for an IT security consultancy and we check the fingerprints before connecting). Otherwise, at least it's trust on first use as Sjoerd already mentioned, so it can't just change without you noticing. An attack would have to be present from the start, and has to go on indefinitely, for it to go unnoticed.

It feels like a design flaw: a malicious server can impersonate a user to a legitimate server by doing MiTM and proxying user's responses to the original server.

Same with any other scheme, right? You can always MitM and proxy the traffic. In ssh's case you get a wrong fingerprint the first time or a fat alert upon any subsequent connections, and in https' case you get a certificate warning.

The way to fix that would be to sign not only challenge, but also server's fingerprint. Then the server can detect MiTM server-side.

Think this through:

A: Hello there, SSH server of bob.example.com!
B: Greetings, stranger. Here is my public key: abcdef
M: intercepts the message and changes abcdef to 123456
A: Hi server bob with public key 123456, I'm Alice with password bz8iuqw45.
M: intercepts the message and changes 123456 to abcdef
B: Hi Alice! You logged in successfully!

An attacker will use their own public key, so they can decrypt the traffic. When forwarding the data, they can replace the fingerprint. You would have to do mutual authentication, where the client supplies a public key that is already trusted by the server. Only then does the server know for sure that the client is using the right key and is not being man-in-the-middled. But now you reversed the problem: now the server has to know the right fingerprint (of the user's public key) instead of the user of the server. The issue, key distribution, remains.

Let's assume that the client is unwiling to check the fingerprint because in order to do it it should get the true fingerprint somehow.

Do you mean it's impossible to get the fingerprint, without trusting the fingerprint when connecting? Because you could grab the real fingerprint when installing the server, before connecting via ssh.

I feel like some clients don't check fingerprints at all

That would be a vulnerability in the client. If you want to check fingerprints but your client does not support that, then you can't use those clients. It's a little easy to say "the authors of the ssh protocol did it all wrong, this is causing clients to ignore security", because as I said, there are pros and cons to this default scheme. If you want to change it, SSH supports certificate authorities as paj28 mentioned.

  • The problem is that Git is built on top of SSH, and I feel like some clients don't check fingerprints at all because the author of the client would have to implement TOFU himself, so he have just disabled this feature. And also TOFU is a usability issue. So as a defence in depth measure, MiTM may be mitigated server-side if the mentioned protocol used. – KOLANICH May 13 at 9:29
  • 2
    @KOLANICH "Since the auth message will contain attacker's server fingerprint, the benign server would reject that message." Please read my answer again. Any MITM will change the server's fingerprint, so they can decrypt the client's response, change the contents of the response to include the correct fingerprint, and send that to the benign server. That is not the "signature scheme [being] malleable", that is the server and client not knowing each other's keys. Key distribution problem. – Luc May 13 at 10:13
  • 1
    @Luc for things like Git, the user's public key is often distributed out-of-band to the server (e.g. by uploading it on Github's website). That is what we can build on (and what actually already works, as detailed by the other answer). If the server doesn't know the user's public key, public key authentication won't work at all anyways. – Paŭlo Ebermann May 13 at 18:55
  • 1
    @PaŭloEbermann Mind that "public key" was never mentioned by OP. They were asking about ssh in general. It seems my answer no longer completely matches the question... after the question was changed. – Luc May 13 at 19:56
  • 1
    @KOLANICH: if your concern is actual git and not merely 'like' git, git does not require ssh – dave_thompson_085 May 14 at 3:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.