SSL man-in-the-middle attacks becoming institutionalized

This post is going to sound crazily tinfoil-hat- and conspiracy theory-like, but I think it highlights a realistic threat to security on the net, especially considering how more protocols (e.g., OAuth2) are relying on SSL alone for message integrity.

Bruce Schneier writes of single-purpose devices that run man-in-the-middle attacks on SSL connections. Supposedly the devices have one ethernet port in, one port out, and are battery powered. They have custom SSL certificates loaded in them that are signed by real Certificate Authorities (CA) under the order of Department of Homeland Security and other Federal organizations (outside the US as well). They attack SSL.

What does that mean? You direct your browser (for example) to Chase.com and log in over HTTPS. You see the lock icon, everything goes just fine. However, what you don't realize is the cryptographic keys (public/private) used in this transaction actually belong to someone else, not Chase Bank, which means someone else now has your password and access to your bank account. Doh! The cause of the breach is your browser, which relies on a chain of trust to validate secure sites like Chase.com. In this case, a root CA has abused the trust chain by issuing a certificate claiming to be Chase.com for an attacker (like the US government). The worst part is your browser won't even tell you that there's a chance this has happened.

But your browser does notice. The browser sees that the certificate's fingerprint has changed and could prompt you to verify that it's okay to proceed. This Firefox plug-in does exactly that, but I think (respectfully) that this doesn't address the fundamental issue of certificate authority trust violation. What would happen if fake certificates became common? Would users care when they're prompted? Doubt it. And the potential for rogue CAs is increasing.

I discussed a solution with Tantek the other day. The concept here is browsers require every site on the web with HTTPS to use its last/old certificate to sign its current/new one. This provides an uninterrupted chain of trust from the host itself. All the client needs is a way to discover the list of historical certificates (probably using something in .well-known) and the code to verify them. The one missing piece is initial indication that the site's certificate is correct a single time (the foundation of trust). Tantek suggested this could be solved socially, with your browser checking with your friends' browsers to see what certificates they've seen (by fingerprint) and looking for consensus. You could probably even do it with a peer-to-peer network of SHA1 hashes.