A history of device-bound cookies

The recent announcement from Google about Device Bound Session Credentials (DBSC) sent me down memory lane.

Back when several TLS attacks were discovered, attacks that could let remote adversaries decrypt HTTPS cookies, I went searching for a stronger defense.

That is when I ran into Dirk Balfanz. He told me about Channel ID, or Channel-Bound Cookies. Dirk was one of the inventors of the security key, which I still consider one of the best security inventions of the past twenty years. When he spoke about authentication, I paid close attention.

Channel ID worked by giving each client machine a unique public key. During the TLS handshake, the client proved possession of the matching private key through a TLS extension. In effect, it was like TLS client authentication, only simpler because it avoided the complexity of renegotiation and certificates.

Cookies issued to the machine would then be bound to that machine ID. If the private key lived inside a security key or a TPM, the cookies could only be used on that specific machine. In theory, cookie theft would no longer be possible.

I loved the idea and volunteered to help make it real. That required changes in both Chrome and Google Accounts, the enormous authentication system behind all Google products. Google was so open at the time that a random engineer like me could contribute code, with reviews of course, to such critical infrastructure.

Most of my time, however, went into debugging. There were endless false positives. Broken TLS setups would cause machine IDs to change, and the server would mistakenly flag legitimate sessions as stolen cookies.

The deeper problem was that we could not find a single confirmed case of a Googler’s cookies being stolen. Maybe it never happened during the quarters I poured myself into the project. Or maybe it did, and those signals were simply lost in a flood of false alerts.

This was my 20% project. And when a 20% project stalls, you pick another. Eduardo soon asked me to implement PGP in JavaScript, which sounded much more fun than wrestling with TLS handshakes, so I told Dirk I was moving on.

The Channel ID project failed, but it taught me a lasting lesson: security is not just about finding vulnerabilities. Real impact comes from building secure products and a safer Internet. Bug hunting is only one path. Security engineers must also fix issues and design systems that neutralize whole classes of flaws. This belief continues to guide our work at Calif.

Fast forward to today. The new DBSC proposal has the same goal as Channel ID, stopping cookie theft by binding cookies to machines, but with important differences. Instead of anchoring the machine ID in TLS, it shifts up the stack to HTTP. And instead of a single machine ID across all connections to a domain, which could become a tracking vector, it uses unique session IDs managed with simple HTTP requests and responses.

And apparently, this simple design works!