In Section 6 of the Universal 2nd Factor (U2F) Overview, where MITM attacks are discussed – near the end of the section, it reads:
It is still possible to MITM a user's authentication to a site if the MITM is
a. able to get a server cert for the actual origin name issued by a valid CA, and
b. ChannelIDs are NOT supported by the browser.
But this is quite a high bar.
I’m not convinced that this is such a high bar. We’ve seen more than a few cases where attackers have been able to obtain fake-but-trusted CA-signed certs. And, TLS ChannelID has not been widely adopted by most browsers and servers (in fact, the RFC draft proposal expired in 2013). Moreover, even if TLS ChannelID is supported by both endpoints, an active MITM attacker could prevent TLS ChannelID from being used by way of a downgrade attack during the ClientHello message.
I applaud the leap that FIDO has made to reduce our reliance on passwords, and to make authentication more secure and less cumbersome for users. But, it seems that it has done little to protect against an MITM attack where an attacker is able to get his hands on a fake-but-trusted certificate, and we must continue to put our full faith and trust in CA’s, which have a history of letting us down. Of course, even the most secure authentication protocol is useless if the connection can be compromised by an active MITM attacker.
Other key-based authentication protocols (such as SSH) protect against MITM attacks by way of public key pinning built-in to the protocol. With SSH, for instance, clients store the public keys of servers that they’ve connected to. Immediately after a connection is made, during key exchange and before any client authentication is attempted - the client verifies that it is indeed connected to the intended server, by checking that the public key that the server is using is the same as the one on file for that server, and ensuring that the server is in possession of the private key associated with the public key via some cryptographic operation requiring the private key.
Of course, HPKP (without FIDO) can be used to pin sites’ SSL/TLS certificates in the browser, but this has its own set of problems.
I’m curious why the architects of FIDO UAF and U2F did not take the protocol a step further, and embed a method of public key pinning within the protocol (perhaps using different keypairs than the ones used for the SSL/TLS connection), so that clients could ensure that they are connecting to the legitimate server before attempting to authenticate, a la SSH. Would anyone care to hypothesize?
