Confirmed users
299
edits
SecurityEngineering/Certificate Verification: Difference between revisions
Jump to navigation
Jump to search
SecurityEngineering/Certificate Verification (view source)
Revision as of 20:38, 24 July 2014
, 24 July 2014→Certificate Verification in Firefox As of Version 31
| Line 19: | Line 19: | ||
== Certificate Verification in Firefox As of Version 31 == | == Certificate Verification in Firefox As of Version 31 == | ||
At the time of the decision to work on mozilla::pkix, we had a number of options: | |||
# We | # We could have fixed the classic verification implementation. As already stated, this would have required considerable work. | ||
# We | # We could have fixed and maintained libpkix ourselves. This was undesirable for the aforementioned reasons. Furthermore, as Google moved away from NSS, we would have had less and less help working on this library. | ||
# We | # We could have used whatever verification implementation Google develops. We would have had to wait a year or more for this, and we would be depending on Google to share their work. | ||
# We | # We could have used OpenSSL's certificate verification routine. Apparently it is buggy as well. | ||
# We | # We could have started over from scratch and written another entirely new verification library. This would have set us back a year. | ||
# Finally, we | # Finally, we could have used the new verification library known as "mozilla::pkix" (formerly known as "insanity::pkix"). This is what we decided to do. | ||
=== mozilla::pkix Design === | === mozilla::pkix Design === | ||
As a library, mozilla::pkix uses the notion of a "trust domain" provided by the application to build a trusted chain from an end-entity certificate to a root. The trust domain is responsible for saying what trust level a certificate has, finding potential issuers of a certificate, and checking the revocation for a certificate. A certificate can be a trust anchor, it can inherit its trust, or it can be actively distrusted. Given an end-entity certificate and a trust domain, the library will perform issuer-independent checks on that certificate (e.g. expiration, appropriate key usages), get a list of potential issuers, and perform a depth-first traversal. If it encounters a distrusted certificate, it abandons searching that path. If it finds a trust anchor, it | As a library, mozilla::pkix uses the notion of a "trust domain" provided by the application to build a trusted chain from an end-entity certificate to a root. The trust domain is responsible for saying what trust level a certificate has, finding potential issuers of a certificate, and checking the revocation for a certificate. A certificate can be a trust anchor, it can inherit its trust, or it can be actively distrusted. Given an end-entity certificate and a trust domain, the library will perform issuer-independent checks on that certificate (e.g. expiration, appropriate key usages), get a list of potential issuers, and perform a depth-first traversal. If it encounters a distrusted certificate, it abandons searching that path. If it finds a trust anchor, it queries the trust domain again to see if that path is acceptable (here is where we check key pinning). If so, the end-entity certificate has successfully been verified. | ||
Unlike the NSS libraries, mozilla::pkix is written in C++. As a result, we can use scoped data types that automatically clean up after themselves rather than having to manually manage memory. This reduces memory-safety bugs as well as error-handling bugs. | Unlike the NSS libraries, mozilla::pkix is written in C++. As a result, we can use scoped data types that automatically clean up after themselves rather than having to manually manage memory. This reduces memory-safety bugs as well as error-handling bugs. | ||
=== Progress === | === Progress === | ||
We have been working on this project for a long time. Last year, progress was slower than everyone would have liked. However, starting in late January, development picked up considerably to the point where we had landed a working implementation (albeit with no OCSP checking) within a month. Since then, we have landed OCSP checking and test improvements, and | We have been working on this project for a long time. Last year, progress was slower than everyone would have liked. However, starting in late January, development picked up considerably to the point where we had landed a working implementation (albeit with no OCSP checking) within a month. Since then, we have landed OCSP checking and test improvements, as well as an OCSP cache. In fact, we managed to have a sufficiently complete and interoperable implementation for it to be released in Firefox 31 on July 22nd, 2014. | ||
The library code is here: https://mxr.mozilla.org/mozilla-central/source/security/pkix/ and the trust domain is here: https://mxr.mozilla.org/mozilla-central/source/security/certverifier/ | The library code is here: https://mxr.mozilla.org/mozilla-central/source/security/pkix/ and the trust domain is here: https://mxr.mozilla.org/mozilla-central/source/security/certverifier/ | ||
| Line 39: | Line 39: | ||
Due to the sensitive nature of this code, we want to ensure proper testing. To that end, we first made sure the new implementation passed the same tests as the current implementation. We then added more tests, finding some bugs in both implementations in the process. At this point, while we will add still more tests, we believe it would be beneficial for the community at large to inspect the design and implementation of the code. Note that this stems not from a lack of confidence in code quality but rather the understanding that the privacy of our users depends on the correctness of this code. | Due to the sensitive nature of this code, we want to ensure proper testing. To that end, we first made sure the new implementation passed the same tests as the current implementation. We then added more tests, finding some bugs in both implementations in the process. At this point, while we will add still more tests, we believe it would be beneficial for the community at large to inspect the design and implementation of the code. Note that this stems not from a lack of confidence in code quality but rather the understanding that the privacy of our users depends on the correctness of this code. | ||
Matt Wobensmith just completed compatibility-testing of 200k HTTPS sites and found 16 with issues. These | Matt Wobensmith just completed compatibility-testing of 200k HTTPS sites and found 16 with issues. These were investigated and resolved to our satisfaction. | ||
=== Implementation status === | === Implementation status === | ||