Either way, if the guy wants 500 starts to implement a security tool and advance security for the world, a gold star he gets.
Either way, if the guy wants 500 starts to implement a security tool and advance security for the world, a gold star he gets.
https://en.wikipedia.org/wiki/SSHFP_record
described in
https://datatracker.ietf.org/doc/html/rfc4255#section-3
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.
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.
I don't turn it off, because I like the warning, but dhcp has made me completely blind to server keys.
I use this all the time, because my AWS/Azure/GCP ips change constantly, but their pubkey fingerprints do not.
[1] https://www.schneier.com/blog/archives/2005/05/the_potential...
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 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?
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