Tag Archives: trust
Suffice to say, the Certificate Authority trust model seems to be fundamentally broken, and with increasing attention paid to it from numerous angles, it’s likely to need a massive overhaul before getting any better. However, there are efforts underway to change the way we think about trust in this capacity. Moxie Marlinspike, known for his contributions to (breaking) SSL and the CA system (among other things), recently developed an alternative to the traditional CA trust model. The project, called Convergence, pairs a Firefox add-on with a set of server-side components to help validate the authenticity and trustworthiness of a particular SSL-enabled site.
Although Moxie’s blog post (that led up to Convergence) and the video of his talk at BlackHat USA 2011 explain the rationale a bit more, the concept is simple: you visit a (SSL-enabled) site, let’s say SomeTrustedSite.com, and the Convergence add-on sees a certificate with a fingerprint FOO. The add-on asks a set of Convergence “Notary servers” what they see. If they see FOO, you can reason that SomeTrustedSite.com‘s cert is legit. If one or more of the notaries sees something that isn’t cert fingerprint FOO, something’s probably rotten (such as man-in-the-middling of your connection, or a notary’s connection, or some other network nastiness). Most importantly, you decide which notaries you want to trust, rather than relying on a browser-vendor defined list of Certificate Authorities. Convergence also attempts to anonymize inquiries to notaries so as to minimize the likelihood of a notary getting a bit too privy to your browsing habits.
Per the Convergence site, the installation process for the add-on is fairly straightforward: run Firefox, visit Convergence.io, click “Download”. After that, add any notaries you wish to trust — two Thoughtcrime notaries are enabled by default, and there’s an ever-growing list of additional notaries on the project’s Github wiki. As this project caught our eye, Intrepidus Group decided to spin up a notary server of our own, which can be added by loading our notary file (if you have Convergence installed, you can simply browse to “.notary” files/links to add the associated notary info).
And Intrepidus isn’t the only company to get on the Convergence notary server train. Late last month, Qualys announced their support of the project, as well as spinning up two notaries. We certainly hope to see more of this type of backing in the near future, and encourage others to run their own notaries as well.
SSL PKI is designed to do two things: encrypt data on the wire, and allow web site validation through the use of trusted third party signatures. The former works pretty well, the Debian weak key debacle aside. Unfortunately, the latter seems about as robust and secure as Windows 98. Case in point, https://discovercard.com. As my colleague Mike Walker points out, DiscoverCard.com forces users to enter credentials on a page served over an insecure HTTP connection. In doing so, Discover leaves users with no real way to tell who they are giving their credentials to. This is a perfect example of an implementation specific design flaw that fails open and renders SSL site validation useless.
Unfortunately, Discover Card isn’t the only organization breaking PKI. The pillars of Internet security, our trusted third party Certificate Authorities, have been having a rough time recently. A number of implementation specific flaws at multiple CAs have allowed outsiders to abuse their systems and obtain certificates for which they are not authorized to hold. Sure, these implementation specific flaws can be fixed, but the lasting damage to the trust we have in PKI can’t be undone. Further, the way PKI has been handling these situations seems to further undermine whatever trust remains.
Last summer when I disclosed the details of how I got the live.com certificate to Microsoft, I told them I wasn’t going to do anything bad with it, they said thanks, we shook hands, and that was pretty much the end of it. A few weeks ago, when Sotirov and crew disclosed that they derived their very own key capable of signing certificates that would be trusted by all web browsers, the researchers told Microsoft, Mozilla, etc, that they wouldn’t do anything bad with it. These companies again said thanks, hands were shook, and that was pretty much the end of that.
We rely on WebTrust audits and other mechanisms to ensure that our commercial Certificate Authorities do their job well, and so we can be sure we’re sending our data to the web sites we trust. Unfortunately, when the audits are useless and the Certificate Authorities screw up like they did in the above two scenarios, companies like Microsoft and Mozilla are forced to make a tough call:
a) Revoke the root CA for which a duplicate signing key was derived by unknown individuals, thus breaking the Internet for many businesses and individual users
b) Do nothing and trust that these guys really only have an expired certificate, and didn’t generate one valid for the next couple of years since they so very easily could have.
In the end, the trust that backs PKI is replaced with the trust of a few select individuals at the organizations who manage our root certificate programs (a.k.a the browser vendors). The millions of dollars spent on web trust audits are meaningless. The CAs could have just paid all of their money earmarked for audits to Sotirov and Appelbaum in exchange for their silence, and PKI would lived to fall another day.
Burn your SSL Certificates?
PKI, while good on paper, is hard to implement securely. It has taken almost two decades for us to have web browsers that actually support the one method that PKI has to protect itself from rogue certificates: Certificate Revocation Lists. And it doesn’t really matter, since not everyone is using IE7 or Firefox 3 yet. CRLs, which are essentially blacklists, are completely ineffective when you don’t even know what rogue certificates are actually in existence.
I don’t think trusted third parties are enough. We need technology that puts the ability to make trust decisions back in the hands of end users, rather than trying to make these decisions for them.
So what can we do differently? I’m of the mindset that client side certificate / public key caching, like that of SSH, can drastically improve our ability to make trust decisions when communicating on the Internet. SSH shows us that we can communicate securely without trusted third parties. The next question is how best to apply this to web browsers. Hashes of public keys are not easily consumed by casual Internet users. Another Intrepidus colleague, Aaron Rhodes, brought up the idea of vanity hashes that are actually easily recognizable patterns. This could help, but it would certainly complicate key management.
In an effort to actually try and help make things better, rather than just ranting about how bad PKI is on this blog, I’ve actually been working on a plug-in for Firefox that lets users white list SSL public keys SSH style and alerts the user when they change. It is actually alot harder than it would seem. In my next post, I’ll talk more about this plug-in, and the challenges I’ve faced in getting it working.