Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
CA/WoSign Issues: Difference between revisions
Jump to navigation
Jump to search
Update section titles
(Remove questionable assertion) |
(Update section titles) |
||
| Line 50: | Line 50: | ||
WoSign has since updated their system to use better locking. | WoSign has since updated their system to use better locking. | ||
===Further Comments and | ===Further Comments and Conclusion=== | ||
Issuing two different certs with the same serial number is a violation of the RFC, but the impact of this bug is minimal. | Issuing two different certs with the same serial number is a violation of the RFC, but the impact of this bug is minimal. | ||
| Line 70: | Line 70: | ||
This issue is also covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report]. They explain that there were two bugs which led to the same result - one involving a system which did not understand serial numbers with leading zeroes, and the other a race condition. | This issue is also covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report]. They explain that there were two bugs which led to the same result - one involving a system which did not understand serial numbers with leading zeroes, and the other a race condition. | ||
===Further Comments=== | ===Further Comments and Conclusion=== | ||
This last auditor statement ("follow up action was also conducted to prevent the recurrence of the incident") is relevant given later issues involving duplicate serial numbers. | This last auditor statement ("follow up action was also conducted to prevent the recurrence of the incident") is relevant given later issues involving duplicate serial numbers. | ||
| Line 98: | Line 98: | ||
This issue was included in Google's report to Mozilla in August 2016 but not listed in the original public discussion. This issue is covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report]. | This issue was included in Google's report to Mozilla in August 2016 but not listed in the original public discussion. This issue is covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report]. | ||
===Further Comments=== | ===Further Comments and Conclusion=== | ||
WoSign acted quickly to resolve the issues, but this issue perhaps demonstrates that their CPS was not a definition of their practice, but more a document to be updated post-hoc to match changes made to their operations. | WoSign acted quickly to resolve the issues, but this issue perhaps demonstrates that their CPS was not a definition of their practice, but more a document to be updated post-hoc to match changes made to their operations. | ||
| Line 138: | Line 138: | ||
This issue is also covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report]. | This issue is also covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report]. | ||
===Further Comments and | ===Further Comments and Conclusion=== | ||
It is the responsibility of the CA to disclose issues to its auditors, not for the auditor to discover them. WoSign was aware of this, because some of the issues in this document were disclosed to auditors and included in their report. | It is the responsibility of the CA to disclose issues to its auditors, not for the auditor to discover them. WoSign was aware of this, because some of the issues in this document were disclosed to auditors and included in their report. | ||
| Line 190: | Line 190: | ||
Looking at their list of misissued domains in the report, this really does mean "any domain". For example, a cert where the owner validated "netwi.ru" was able to add "mx.idisk.su", an entirely different domain, without validating it. This effectively bypasses domain validation for any attacker who owns a domain of their own. | Looking at their list of misissued domains in the report, this really does mean "any domain". For example, a cert where the owner validated "netwi.ru" was able to add "mx.idisk.su", an entirely different domain, without validating it. This effectively bypasses domain validation for any attacker who owns a domain of their own. | ||
===Further Comments and | ===Further Comments and Conclusion=== | ||
* An arbitrary unvalidated ownership domain misissuance bug is an extremely serious flaw, particularly if it's available in a normal workflow. | * An arbitrary unvalidated ownership domain misissuance bug is an extremely serious flaw, particularly if it's available in a normal workflow. | ||
| Line 221: | Line 221: | ||
This issue is also covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report]. | This issue is also covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report]. | ||
===Further Comments=== | ===Further Comments and Conclusion=== | ||
There are plenty of ways of testing this scenario without using public roots - and, in fact, WoSign has updated their systems to avoid issuing test certificates from public roots in future. | There are plenty of ways of testing this scenario without using public roots - and, in fact, WoSign has updated their systems to avoid issuing test certificates from public roots in future. | ||
| Line 323: | Line 323: | ||
This issue is covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report]. Of the 64 certificates they consider, WoSign attribute 6 to a dual-issuance bug, 9 they say are not problematic because they were issued on December 31st 2015, 2 are the mis-issued certs relating to Issue V, and the other 47 are "normal SHA-1 orders". | This issue is covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report]. Of the 64 certificates they consider, WoSign attribute 6 to a dual-issuance bug, 9 they say are not problematic because they were issued on December 31st 2015, 2 are the mis-issued certs relating to Issue V, and the other 47 are "normal SHA-1 orders". | ||
===Further Comments | ===Further Comments=== | ||
Mozilla is seeking further information on the details in WoSign's report and will make further comment at a later date. | Mozilla is seeking further information on the details in WoSign's report and will make further comment at a later date. | ||
| Line 364: | Line 364: | ||
2016-09-04: [https://www.wosign.com/report/wosign_incidents_report_09042016.pdf Official issue report]. This issue is also covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report]. | 2016-09-04: [https://www.wosign.com/report/wosign_incidents_report_09042016.pdf Official issue report]. This issue is also covered in WoSign's [https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf final incident report]. | ||
===Further Comments=== | ===Further Comments and Conclusion=== | ||
* This issue does not paint a picture of careful software development practices and quality assurance - having unused code around capable of issuing BR-violating certificates does not seem like responsible practice. | * This issue does not paint a picture of careful software development practices and quality assurance - having unused code around capable of issuing BR-violating certificates does not seem like responsible practice. | ||