search

rpwoodbu / mosh-chrome

Mosh for Chrome
GNU General Public License v3.0
372 stars 59 forks source link

SHA-256 SSHFP records don't validate #146

Closed oskar456 closed 7 years ago

oskar456 commented 7 years ago

I have a SSH server with bunch of SHA-2 SSHFP records:

$ dig +short oskarpc.cesnet.cz sshfp
1 2 E9A95510E1313546C7CDE4C3AC3394D43E4294A307881A26DA5961F4 1EF41CCC
3 2 A9D2176488C6A0F4ED8A19FCB24183966EEC6B9D7DD752BEA56FF505 281C7ED1
4 2 E226E7EF6E770973DA331D5F98449C9A524B8DAEE551E6D365246631 31A5BAF6

Even though the fingerprint is valid (I use it daily from a Linux machine) when used by Mosh app, I'll get this scary warning:

Authenticated DNS lookup.
Found authentic SSHFP fingerprint record(s) in DNS.
Remote ssh host name/address:
  oskarpc.cesnet.cz:22
Authenticated SSHFP DNS record(s) do not validate the host key!

Likely man-in-the-middle attack or misconfiguration.

SSHFP records(s) are:

  1 2 e9a95510e1313546c7cde4c3ac3394d43e4294a307881a26da5961f41ef41ccc

  3 2 a9d2176488c6a0f4ed8a19fcb24183966eec6b9d7dd752bea56ff505281c7ed1

  4 2 e226e7ef6e770973da331d5f98449c9a524b8daee551e6d36524663131a5baf6

SSH Login failed.

I guess the problem would be in SHA-256 fingerprints not supported. This should be fixed by either validating SHA-256 (according to RFC 6594 SHA-1 fingerprint should not be considered when there is are SHA-256 fingerprints present) or set up in a way that SSHFP records with type 2 fingerprint are not considered at all. The former fix is obviously preferred.

rpwoodbu commented 7 years ago

Mosh for Chrome doesn't currently support SHA-256 (see here). It really needs to (especially in light of SHA-1 being "SHAttered"), but when I wrote this, the version of libssh I was using didn't have support for that hash, and I didn't have time to dig deeper.

The code only checks for SHA-1, and since you have none, it is in a quandary. I'm thinking the right behavior is to act like there was never any SSHFP record at all, and fall back to the "make the user check the fingerprint" behavior.

Of course, getting SHA-256 support is preferred (as you say), but even then, if a new unsupported hash is introduced, the behavior needs to be right.