I'm actually surprised the ssh protocol doesn't have MITM mitigation built in. Part of the original U2f Spec was that the TLS session State could be hashed and included as part of the client signature, effectively making MITM impossible. I don't believe this was widely implemented in practice however, although it seems like ssh would be a much better target to implement this behavior.
Either way, if the guy wants 500 starts to implement a security tool and advance security for the world, a gold star he gets.
That's not completely correct surprisingly. You can put SSH public keys into DNS records with the SSHFP type and use DNSSEC to have a complete trust chain rather than using TOFU. It's disabled by default in OpenSSH however, and I'd be pretty surprised if there was any large group of people making use of it presently.
I found it amusing that all it changes is a single line in the TOFU output, adding "Matching host key fingerprint found in DNS." among all the other scary warnings.
> I'm actually surprised the ssh protocol doesn't have MITM mitigation built in. Part of the original U2f Spec was that the TLS session State could be hashed and included as part of the client signature, effectively making MITM impossible.
When you use SSH public key authentication, a hash of the key exchange (called the "session identifier") is included in the client signature, much like the U2F channel binding you describe: https://datatracker.ietf.org/doc/html/rfc4252#section-7
This provides the same amount of protection as the U2F channel binding: namely, the MitM is unable to forward the signature to the server and successfully authenticate to the server as the client.
However, neither SSH nor U2F channel binding prevents the MitM from impersonating the server and hoping the client transmits something confidential. The SSH-MITM tool supports redirecting clients to a honeypot for this purpose.
Additionally, if the SSH client has agent forwarding enabled, the MitM can just ask the client to sign a new signature in order to authenticate to the server. The SSH-MITM tool also supports this.
Bottom line, no amount of channel binding in the authentication protocol is a substitute for correctly validating the server's identity, especially if you have SSH agent forwarding enabled.
You can search `known_hosts` for a fingerprint using `ssh-keygen -l -f ~/.ssh/known_hosts` and `grep`. If you disable `HashKnownHosts` in your ssh config, the command will also tell you the name of the host(s) for that fingerprint, rather than its hash.
I use this all the time, because my AWS/Azure/GCP ips change constantly, but their pubkey fingerprints do not.
> Part of the original U2f Spec was that the TLS session State could be hashed and included as part of the client signature, effectively making MITM impossible.
This turns out to have the usual deployment hiccup, Middleboxes. In this case, at least, they've got some sort of consent, the user agent is agreeing to trust this middlebox which is not, in fact, the host it wanted to talk to. But it necessarily blows up export of session identifiers which was needed to make this U2F feature work.
The session between Alice and her BigCorp middlebox, and the session between the BigCorp middlebox and Bob's server are two different sessions (if you try to make it "one session" you don't have working middleboxes unless clients and servers only know TLS 1.2 or earlier), so, this shows up as MITM.
Which makes sense, the goal is to ensure MITM is impossible, these consensual Middleboxes are MITM, so it makes them impossible. But as a practical technology you can't deploy it because ordinary Joe User works at some company using such middleboxes and now their U2F sign-in doesn't work.
> I'm actually surprised the ssh protocol doesn't have MITM mitigation built in.
I don't understand, doesn't it? If the key for a host changes, it throws a scary warning. If you haven't connected to a host before, you're asked to trust the key. How does this utility manage to MITM exactly?
This utility can only perform MitMs if the client doesn't correctly verify the server's identity - e.g. if the user doesn't verify the fingerprint during the first connection, or they override the scary MitM warning. If the client correctly verifies the server's identity, then MitM is not possible.
exabrial is referring to a mitigation that works even if the client doesn't correctly verify the server's identity. SSH actually does have this mitigation, but it doesn't fully prevent nastiness, as I explain here: https://news.ycombinator.com/item?id=29259981
Either way, if the guy wants 500 starts to implement a security tool and advance security for the world, a gold star he gets.