8

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?

weaver
  • 311
  • 3
  • 4
  • Because pinning is *extremely* difficult to get right, it has a huge cost of entry, and you brick everyone's registered token if you do it wrong. – Steve Apr 20 '17 at 21:09
  • Is this MITM during authentication or registration? If during authentication, then would the MITM be able to spoof the origin host name (the verifiable value to which was set during registration)? – katrix Apr 20 '17 at 21:14
  • Steve: Thanks for your comment. I'm referring to certificate pinning akin to what is used in SSH (rfc-4252). – weaver Apr 21 '17 at 00:49
  • Katrix: Thanks for your comment. Yes, during authentication, assuming the MITM would be able to spoof the origin host name (as set during registration) via an attack where the attacker is able to obtain a fake-but-valid CA-signed certificate, a la https://www.eff.org/deeplinks/2011/09/post-mortem-iranian-diginotar-attack – weaver Apr 21 '17 at 00:54
  • 1
    This type of certificate pinning would have negative side effects if the certificate has to be renewed. Especially with let's encrypt where the certificates are only valid for a short time. Additionally, another hurdle would be the key handle which the MitM would need to provide with the challenge. This would probably be easily doable but still, need some extra work. Certificate transparency also plays into this as now the CA's can be observed on how they give out invalid certificates. This makes FIDO U2F stronger. (Sorry for necro this post but I just had a session about this in my studies. – Tartori Jan 25 '19 at 20:22

1 Answers1

1

I share your global feeling about U2F being a good job even if it is an half-done job. :) Note: I am working as a security architect inside a small company (FIDO Alliance member) with its own U2F certified products.

Regarding expiring TLS ChannelID support, it is supposed -eventually- to evolve into Token Binding support (updated specifications, same goal). https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ Yes, it is not easy to implement TlS Channel ID on the server side (BoringSSL library can help) and yes it is only supported by Chrome on the client side and yes, it can be downgraded... BUT the good thing is that if you are thinking about using U2F on your own server/service, it can still be done and you can enforce it. Better than nothing while it is true that on many global services (gmail, facebook...), TLS Channel ID protection is simply deactivated.

Regarding the key pinning debate and why the server authentication part is relying on good/bad old SSL server certificate, the original decision is probably a mixed result of technical difficulties and "political" positioning. U2F (and UAF) already attacks established Certificate Authorities on the client side... Note : these are anonymous client key pairs but associated attestation/production certificates can be signed by FIDO Alliance private keys (becoming its own Certificate Authority...).

Dealing with mutual authentication would require larger memory too... I don't care, but it can be a problem for some solutions providers.

Whatever the initial real reason, it is not done and as far as I know, this kind of feature is not planned for future U2F releases... and not planned either for WebAuthN (kind of U2F/UAF successor).

But it doesn't mean U2F can't be adapted to support enhanced mutual authentication feature... I am working on it with few other fools: Welcome to our madness :)

FredericMARTIN
  • 581
  • 3
  • 8