Created attachment 2183 [details] Fix downgrade attack vulnerability in handling SSHFP records To quote RFC 6594, section 4.1.: > Secure Shell implementations that support SHA-256 fingerprints MUST prefer a SHA-256 fingerprint over SHA-1 if both are available for a server. If the SHA-256 fingerprint is tested and does not match the SSH public key received from the SSH server, then the key MUST be rejected rather than testing the alternative SHA-1 fingerprint. The current version of SSH does not conform this requirement. Attached patch fixes this issue. It can be tested using this command: $ ssh -vv -o HostKeyAlgorithms=ecdsa-sha2-nistp521 -o VerifyHostKeyDNS=yes sshfp-test-downgrade.oskarcz.net (The SSHFP records with SHA-256 digests for hostname sshfp-test-downgrade.oskarcz.net are intentionally altered.)
Created attachment 2184 [details] Handle future digest types correctly When testing, I also found out that when a SSHFP record for the host uses digest type other than SHA1 or SHA256, the SSHFP check fails even if SHA1 or SHA256 matches the offered host key. This patch changes this behavior to ignore future digest types.
(In reply to comment #1) > Created attachment 2184 [details] > Handle future digest types correctly > > When testing, I also found out that when a SSHFP record for the host > uses digest type other than SHA1 or SHA256, the SSHFP check fails > even if SHA1 or SHA256 matches the offered host key. > > This patch changes this behavior to ignore future digest types. Feel free to test it using ssh -vv -o VerifyHostKeyDNS=yes -o HostKeyAlgorithms=ecdsa-sha2-nistp521 sshfp-test-newdigest.oskarcz.net
Wouldn't it be simpler and safer to verify that all fingerprints match? I.e verify that both SHA1 and SHA256 SSHFP records verify correctly. Right now we need only one success and ignore all the hash mismatches...
Created attachment 2188 [details] Fix downgrade attack vulnerability in handling SSHFP records I realized that only fingerprints for same key algorithm as sshd offered should be counted as found. Otherwise, it would reject SHA-1 SSHFP only because there is a SHA-256 SSHFP for another key algorithm. As usual, testcase is here, having only SHA-1 SSHFP for RSA Host key: $ ./ssh -vv -o HostKeyAlgorithms=ssh-rsa -o VerifyHostKeyDNS=yes sshfp-test-downgrade.oskarcz.net
(In reply to comment #3) > Wouldn't it be simpler and safer to verify that all fingerprints > match? I.e verify that both SHA1 and SHA256 SSHFP records verify > correctly. Right now we need only one success and ignore all the > hash mismatches... This would actually prevent doing a smooth host key rollover, where you pre-publish SSHFP records for the new Host key, then change the host key and delete old SSHFP records after that. As DNS updates are never synchronous, you cannot change SSHFP records at the same moment as host key.
Created attachment 2211 [details] Fix downgrade attack vulnerability in handling SSHFP records Here comes a new version of the patch fixing downgrade vulnerability as the former one did not work well after applying the „future digests“ patch. Instructions counting found DNS records are shifted after hostkey initialization.
Created attachment 2402 [details] Fix downgrade attack vulnerability in handling SSHFP records The same patch, only rebased to OpenSSH 6.4p1 codebase.
Created attachment 2403 [details] Handle future digest types correctly The same patch, only rebased to OpenSSH 6.4p1 codebase. Hoping these patche would be eventually make it to a release. :)