Once the underlying TLS channel uses TLS client authentication (with the TLS-OBC extension
), the server can bind
its cookies to the TLS channel by associating them with the client's public key, and ensuring that the cookies are only ever used over TLS channels authenticated with that public (client) key.
This means that if such a channel-bound cookie is ever stolen off a client's machine, that cookie won't be able to authenticate an HTTP session to the server from other machines. This includes man-in-the-middle attackers that inject themselves into the connection between client and server, perhaps by tricking users into clicking through certificate-mismatch warnings: such a man-in-the-middle will have to generate its own TLS session with the server, which won't match the channel that the cookie is bound it.
It's up to the server to decide whether to bind cookies to TLS channels. If the client doesn't support TLS-OBC
, or if the cookie it's about to set will be used across different origins
, then the server will not channel-bind the cookie. If it does decide to channel-bind the cookie, it should associate the cookie with the client's public key.
This is similar to RFC 5929
, but instead of the client binding data to the server's public key
, in this case the server would be binding data (the cookie) to the client's
public key. The server can do this either by simply storing, in a backend database, the fact that a certain HTTP session is expected to be authenticated with a certain client public key, or it can use suitable cryptography to encode in the cookie itself which TLS client public key that cookie is bound to.
In the figure above, the server includes the client's public key into a cryptographically signed datastructure that also includes the authenticated user's id. When the server receives the cookie back from the client, it can verify that it indeed issued the cookie (by checking the signature on the cookie), and verify that the cookie was sent over the correct channel (by matching the TLS client key with the key mentioned in the cookie).
Benefits of Channel Binding
- Using cookies in this manner means that web applications don't have to change much. They already associate a variety of information with cookies (the user they authenticate, expiration times, etc.) - the client's public key is simply one more piece of information to associate with the cookie.
- Using TLS-OBC and then (perhaps) setting cookies that are (perhaps) channel-bound means that we can keep the existing modes of user interaction that we have today: A user can be logged out (cookie is not set), can be logged into one account (channel-bound cookies is associated with one user id), or can be logged into multiple accounts (channel-bound cookie is associated with multiple user ids). Transitioning between these states uses the same UI it does today (i.e. application-rendered HTML, not browser chrome), and the underlying mechanisms also remain the same (setting/removing cookies).
- The idea of binding cookies to a TLS channel says nothing about how the user authenticates. The user might authenticate with a username and password, or through more sophisticated means. As long as a cookie is set as a result, and that cookie is channel-bound, we gain the advantages of stronger authentication.
- Unlike traditional TLS client authentication, TLS-OBC with channel-bound cookies keeps the TLS terminators in a datacenter out of the trusted computing base. The TLS terminator simply sends information about the client public key and the cookie downstream, where the application logic makes sure that those two match. Just like in traditional cookie-based systems, the TLS terminator can't mint valid cookies, and hence can't impersonate users at will.
- Can't I still steal the private key? Together with a stolen cookie, I can then impersonate the victim.
It depends on the capabilities of the attacker, and the way the private key is stored. If the attacker is in the network, it can't get to the private key. If the attacker has infiltrated the client machine it might be able to get to the private key. What's important to remember is that this model of authentication allows for the credentials (TLS-OBC client private keys) to potentially move into well-protected storage, which is simply not possible for models that rely solely on bearer-tokens.
- What about TLS session state? Together with a stolen cookie, I can then impersonate the victim.
Even if the private key is stored securely in a hardware module, malware might be able to extract certain TLS session state (e.g., the session master secret), and then resume that TLS session from a different location. This can be mitigated by reducing the lifetime of TLS sessions, and by requiring the client to re-submit proof of possession of the private key from time to time. Also, once we move to a model without bearer tokens, one could theoretically imagine a future in which SSL session state is protected by a hardware module as well, just as private keys can be protected in a TPM. Maybe the NIC could implemented TLS in hardware. With cookies and bearer tokens, this is not an option: the application (the browser) must have access to the credentials (the cookies).
- What happens to cookies that are set on a whole domain, and its subdomains?
Since the TLS-OBC spec stipulates that the client-side certificates are per-web-origin, domain cookies might get sent by the browser to different origins, over different TLS channels. Such cookies can't be channel-bound.
- Does this protect against man-in-the-middle attacks?
If we assume that a cookie is bound to the correct channel (i.e., the man-in-the-middle wasn't present when the cookie was deposited), then binding cookies to TLS sessions will indeed protect against man-in-the-middle attackers that are in the network between client and server, even those in which the man-in-the-middle has compromised a Certification Authority and can impersonate the server to the client. Since the man-in-the-middle will have to use its own private key with the server, the cookie that it intercepts and forwards will fail to validate at the server side.