Hello, Andy Steingruebl here:
After the paper a week ago by Chris Soghian and Sid Stamm on the possibility and perhaps high likelihood of a breakdown in the CA trust model due to coerced certificate generation, a lot of attention has focused on how to mitigate this type of attack.
Generally speaking people have been looking to several different solutions to the problem:
- Detection of changes in a given site's CA or Certificate
- Allowing a site to indicate its CA policy via some OOB means
- Alternative means for scoping CA signing rights in browsers so that the trust-root isn't one size fits all.
- Sites advertising their SSL keys via other means than signing by a CA.
I want to focus on just topic #1 in this post and I will write up some further thoughts on #2 , 3, and 4.
Several solutions to detect changes or variances in a site's certificate have been proposed. One of the most prominent and advocated is the Perspectives work (and Firefox plugin) from CMU.
Perspectives works by having a group of "notary" servers on the internet monitoring certain sites, and capable of telling an end-user whether they have a quorum of agreement on the value presented for a given server's certificate. If the version of a certificate that your client sees differs substantially from those seen by a number of notary servers, there is some chance you are suffering a MiTM attack.
These Notary servers can also be used to track the properties of a given certificate over time. If they notice for example that the certificate at https://www.paypal.com/ is usually singed by Verisign (it is) and is an EV certificate, and all of sudden it is signed by some other small CA, then that may be evidence of something like compelled certificate generation.
Just this last weekend we had some security researchers contact us about a number of certificate fluctuations for https://www.paypal.com. Over the last few weeks our certificate changed several times, and in one case for very short period of time. Based on the assumption that certificate fluctuations like this could also be a result of an attacks, the researchers contacted us. (Reminder, we have a contact process for security issues).
Unfortunately, the changes of certificates for www.paypal.com was intentional. We were testing out some new certificates on the PayPal site, and rolled them out in order, and for a short duration. All of the certificates were signed by the same CA as usual, but were distinct from each other and did cause fluctuations within the Perspectives tool.
During the recent Global Symposium on DNS Security, Stability and Resiliency the issue of coherency for DNS came up as a metric to track. One of the hard things to define within the DNS is "right answer" to a query. As it turns out, the best definition we could come up with was - "Client gets the answer to the query that the zone owner intended."
Which bring me back to the point of this post. In the space of Web server SSL certificates, the only point of view of correctness that really matters, is what the server intended to publish. Yes, there is a relying party in this trust relationship (the end user) and they are ultimately responsible for deciding whether to trust a certificate. But the major data point they should consider is what the Site intended, and try to discern that as best they can.
The only party who actually knows what certificate should have been published, is the site owner.
This means that for certain types of prevention and defense against certain attacks, we need to look for options #2,3,4 above to solve the problem, because the current in-band signaling mechanism isn't always up to the task against certain classes of adversaries, and has certain undesirable failure modes.
Comments