By Dirk Balfanz, Google
In the summer of 2011, users in Iran were subject to a man-in-the-middle attack: Someone had stolen TLS certificates from the Dutch Certification Authority DigiNotar, and was using them to impersonate Google and many other destinations on the Internet in Iran. In addition to eavesdropping on their victims, this attacker could have easily stolen cookies and passwords, allowing them to access their victims’ accounts even after the man-in-the-middle attack itself was put to an end.
The Heartbleed Bug that was discovered in 2014 leaked TLS session data from servers around the internet, again including cookies, and perhaps other user credentials such as passwords.
In March, the DROWN attack on TLS showed that many popular sites on the internet have been vulnerable to eavesdropping by men-in-the-middle. If an eavesdropper was able to collect cookies or passwords through this attack, once again users would remain vulnerable even after the attack had been neutralized.
The reason users remain vulnerable even after these kinds of attacks are shut down is that we use bearer tokens for authentication on the internet. A bearer token is a secret that a client comes bearing to the server in order to convince the server that it should be granted access. It’s in the nature of bearer tokens that they can fall into the hands of eavesdropping men-in-the-middle.
FIDO represents a large and concerted effort by more than 250 companies to rid the internet of one of the most notorious bearer tokens: the account password. Instead of a password, FIDO uses a private key as the account credential, which never leaves the user’s computer. If all users subjected to the attacks above had been using FIDO authentication, attackers who are after account credentials would have come away empty-handed.
But account credentials are not the only prize to be gained from such attacks. As already mentioned, cookies can be just as valuable to attackers as passwords; and this list also includes OAuth tokens or other bearer-token session credentials. In order to protect users from attackers that remove such session credentials from one TLS connection and re-use them elsewhere, it is considered good practice to channel-bind session credentials. This means that the session credential (the cookie, the OAuth token, etc.) itself is tied to the underlying TLS connection over which it is sent. If a man-in-the-middle or other credential thief tries to use the credential in another context (i.e., over another TLS connection), the credential will be considered invalid. The original RFC for channel binding specifies two ways of doing this: either by tying the credential to the server certificate, or to a unique “fingerprint” of the underlying TLS connection. Unfortunately, neither of these channel-binding techniques are practical for cookies, which are created by the server and sent to the client; and then frequently (re-)sent by the client over different TLS connections to the server.
Google, Microsoft and others have therefore experimented with a different channel-binding technique, which instead binds the session credential to a client’s key. This means that a server can associate – as it creates a new cookie for a client – this cookie with the client’s public key. Later, when the client sends the cookie back to the server, it must prove possession of the corresponding private key. A cookie thief not in possession of this private key won’t be able to use the stolen cookie.
This technique has gone through a number of iterations (being called “Origin-Bound Certificates” and “Channel ID” along the way), and is currently being standardized by the IETF under the name of Token Binding.
To summarize: in order to deny man-in-the-middle attackers the ability to re-play credentials obtained from eavesdropping on their victims, sites on the internet should use FIDO authentication (to eliminate the risk of stolen passwords) and channel-binding techniques such as Token Binding (to eliminate the risk of stolen cookies). These technologies complement each other, and can be deployed independently.
What we described so far (replacing passwords with client-held key pairs, and channel-binding cookies) would leave one small window of opportunity for an eavesdropper. At login time, the client usually sends a FIDO assertion (i.e., a signature generated with the user’s private key over a server-generated challenge) to the server, which checks it and in return sends a channel-bound cookie back to the client. What if the man-in-the-middle managed to steal that FIDO assertion? The attacker wouldn’t know the user credential (which is a private key safely stored on the client device), but it would have access to the FIDO assertion, and be able to exchange it for a cookie that would then be bound to the attacker’s client instead of the legitimate user’s device. This amounts to hijacking the user’s login session.
FIDO therefore specifies that FIDO assertions can themselves be channel-bound. This means that before sending the FIDO assertion to the server, the client includes information about the TLS connection between client and server into the FIDO assertion, binding it to that TLS connection. FIDO UAF allows all channel-binding mechanisms from RFC 5929, plus Channel ID, whereas FIDO U2F only allows Channel ID. (Token Binding, which replaces Channel ID, wasn’t an IETF draft at the time the FIDO specifications were written. It’s a trivial change in the FIDO specifications to switch from Channel ID to Token Binding.)
Note that the addition of channel-binding information in FIDO assertions is optional: not all client platforms support Channel ID or Token Binding, and even if a client has all the necessary support for channel-binding, it might make sense not to enforce channel-binding. In other words, a FIDO relying party may want to ignore the channel-binding information in FIDO assertions, and choose not to channel-bind its cookies.
Why would a relying party choose not to make use of this extra security measure? Some client networks have deployed proxy servers at the perimeter of their network. These proxies inspect outgoing and incoming traffic for viruses, potential leaks of trade secrets, etc. It’s in the nature of these proxies that they break the channel binding of FIDO assertions or channel-bound cookies. While such networks won’t be able to enjoy the full man-in-the-middle protection of channel-binding, they can still benefit from the security and usability improvements of FIDO authentication.
Therefore, relying parties should be mindful when they do and do not enforce channel binding of cookies and FIDO assertions. For example, they can let users (or enterprise administrators) decide which accounts should be exempt from channel binding. Users or enterprises could choose to opt out of channel binding if they operate in an environment where TLS traffic is being intercepted, while still using FIDO authentication.
To recap: in this TechNote, we discussed three ways to move from bearer tokens (which are susceptible to theft by eavesdropping men-in-the-middle) to more secure forms of authentication:
- Use FIDO authentication instead of (or in addition to) passwords. This is what the FIDO specifications are all about. The benefits here are tremendous: today, most account takeovers stem from phishing attacks or breach of password databases. Both of these attacks are rendered impossible when relying parties adopt FIDO authentication, regardless of whether they also deploy the other two mechanisms below.
- Enforce the channel-binding in FIDO assertions. This is an optional part of the FIDO specification, and depends on the capabilities of the client (does it support Channel ID? Other forms of channel binding?, etc.), as well as the requirements of the client (do they need to intercept TLS traffic before it leaves the client premises?). FIDO relying parties – presumably after consulting with their clients – can choose from a range of options here, including only allowing clients that support channel binding (and enforcing it), ignoring channel-binding information altogether, or something in between (like treating separate user accounts differently).
- Channel-bind the cookies that the server issues. This is outside the scope of the FIDO specifications, and can be done independently of any FIDO deployment. (For example, a server could issue a channel-bound cookie in response to a valid password, instead of a valid FIDO assertion.) Note that the same comments as mentioned above on client abilities and client requirements for man-in-the-middle protection through channel binding apply here, as well.
FIDO TechNotes highlight aspects of the FIDO specifications that are important for practitioners to understand. TechNotes shed light on architectural choices, explain best practices, and give guidance to deployers of the technology. TechNotes are part of an on-going FIDO series featuring the technology and evolution of the FIDO Alliance. Current entries include There Is No Security Without Privacy.
MORE Buying, Building & Partnering
