Closed
Bug 1397832
Opened 7 years ago
Closed 7 years ago
GRCA: Signing SHA-1 OCSP responses with unconstrained certificate
Categories
(CA Program :: CA Certificate Compliance, task)
CA Program
CA Certificate Compliance
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: agwa-bugs, Assigned: gpki)
References
Details
(Keywords: sec-other, Whiteboard: [ca-compliance] [ocsp-failure])
Attachments
(1 file)
2.77 KB,
application/octet-stream
|
Details |
I just sent the following to Government of Taiwan, Government Root Certification Authority (GRCA)'s problem reporting address (egov@service.gov.tw). Note that in the April 2017 CA Communication, GRCA stated that they were no longer using SHA-1 to sign OCSP responses: https://ccadb-public.secure.force.com/mozillacommunications/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00020&QuestionIdForText=Q00026 Your OCSP responder at http://hcaocsp.nat.gov.tw/cgi-bin/OCSP/ocsp_server.exe signs OCSP responses with SHA-1 using a certificate that is trusted by Mozilla for server authentication. This is a violation of section 5.1.1 of Mozilla's Root Store Policy Version 2.5, which states: "CAs MAY sign SHA-1 hashes over OCSP responses only if the signing certificate contains an EKU extension which contains only the id-kp-ocspSigning EKU. ... CAs MUST NOT sign SHA-1 hashes over other data, including CT pre-certificates." Furthermore, since the response reflects an attacker-supplied nonce of arbitrary length, your OCSP responder could allow attackers to forge SHA-1 SSL certificates using a chosen-prefix attack as described here: https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg02999.html I have attached a signed OCSP response as evidence. A copy of this report will be sent to Mozilla.
Comment 1•7 years ago
|
||
Hung-Yu Hsu or Rob Betwu, Please reply in this bug very promptly to acknowledge that you have been informed of this bug, and provide a timeline for resolving the concern. Then please provide an incident report in this bug, as described here: https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report
Assignee: kwilson → gpki
Comment 2•7 years ago
|
||
(In reply to Kathleen Wilson from comment #1) > Hung-Yu Hsu or Rob Betwu, > > Please reply in this bug very promptly to acknowledge that you have been > informed of this bug, and provide a timeline for resolving the concern. It has now been 10 days. Please respond ASAP. Gerv
Assignee | ||
Comment 3•7 years ago
|
||
Incident Report 1.How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, via a discussion in mozilla.dev.security.policy, or via a Bugzilla bug), and the date. -->Via Bugzilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=1397832 at Sep. 23 2017 2.A timeline of the actions your CA took in response. -->Sep. 23: Identify the incident and found that HCA (one of subordinate CA) misunderstood the policy. Sep. 24: Contact the subordinate CA administrator and scheduled to fix the problem before Sep. 27. Sep. 25: Confirm that no other subordinate CA has the same issue. Sep. 30: Confirm the problem were fixed and report to bugzilla. 3.Confirmation that your CA has stopped issuing TLS/SSL certificates with the problem. -->This subordinate CA no longer issues TLS/SSL certificate since Sep. 2016. 4.A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued. -->No problematic TLS/SSL certificates were issued. 5.The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. -->No problematic TLS/SSL certificates were issued. 6.Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. -->The HCA misunderstood the policy and assumed that the SHA-1 policy only apply to certificates. Thus HCA do stop issuing any SHA-1 certificate since last year, however, they forget to replace SHA-1 hash algorithm of OCSP response. GRCA also has not conducted technical review before replying CA communication this April. 7.List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things. -->In order to prevent from subordinate CAs misunderstanding the new policies, GRCA will take following steps when policies change: 1.Gathering all subordinate CAs and explain new policies precisely. 2.Get the schedule of subordinate CAs to conform new policies. 3.Technically review all subordinate CAs and check completeness. These action takes effect immediately.
Comment 4•7 years ago
|
||
(In reply to National Development Council from comment #3) > 2.A timeline of the actions your CA took in response. > -->Sep. 23: Identify the incident and found that HCA (one of subordinate CA) > misunderstood the policy. > Sep. 24: Contact the subordinate CA administrator and scheduled to fix > the problem before Sep. 27. > Sep. 25: Confirm that no other subordinate CA has the same issue. > Sep. 30: Confirm the problem were fixed and report to bugzilla. Can you also please provide the timeline related to compliance steps taken? Such as, when did GRCA first update its policies with respect to the BR change, when did GRCA notify its subordinates of the policy change, were there any other policies or practices GRCA had in place for compliance changes that were followed? > 7.List of steps your CA is taking to resolve the situation and ensure such > issuance will not be repeated in the future, accompanied with a timeline of > when your CA expects to accomplish these things. > -->In order to prevent from subordinate CAs misunderstanding the new > policies, GRCA will take following steps when policies change: > 1.Gathering all subordinate CAs and explain new policies precisely. > 2.Get the schedule of subordinate CAs to conform new policies. > 3.Technically review all subordinate CAs and check completeness. > These action takes effect immediately. Approximately how many independent sub-CAs does GRCA have? Kathleen: From trying to examine the audit information (based on both crt.sh and https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport ), I cannot appear to find a BR audit for these CAs (e.g. https://crt.sh/?id=12714631 or https://crt.sh/?id=12721379 ) The newest statement I could find about BR compliance was in response to the May 2014 communication - https://docs.google.com/spreadsheets/d/1v-Lrxo6mYlyrEli_wSpLsHZvV5dJ_vvSzLTAMfxI5n8/pubhtml - suggesting that GRCA expected an audit to be completed within the year. From looking at the original inclusion bug, GRCA acts as a "Super-CA" - https://bugzilla.mozilla.org/show_bug.cgi?id=274106#c4 - but the audit information provided to the CCADB does not seem to reflect that or be consistent with this response (with respect to audit scope). Given https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Super-CAs , I believe it would be consistent with Mozilla's policies for inclusion to remove this CA, but would be interested in your thinking.
Flags: needinfo?(kwilson)
Comment 5•7 years ago
|
||
(In reply to Ryan Sleevi from comment #4) > Kathleen: From trying to examine the audit information (based on both crt.sh > and > https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport ), > I cannot appear to find a BR audit for these CAs (e.g. > https://crt.sh/?id=12714631 or https://crt.sh/?id=12721379 ) I see that this CA does indeed need to update the Standard Audit and BR Audit information for all of their subCAs in the Common CA Database very promptly. Here's the 2017 Audit statements I am aware of: https://cert.webtrust.org/SealFile?seal=2252&file=pdf SHA-256 Fingerprints of certs in scope of audit: 76:00:29:5E:EF:E8:5B:9E:1F:D6:24:DB:76:06:2A:AA:AE:59:81:8A:54:D2:77:4C:D4:C0:B2:C0:11:31:E1:B3 70:B9:22:BF:DA:0E:3F:4A:34:2E:4E:E2:2D:57:9A:E5:98:D0:71:CC:5E:C9:C3:0F:12:36:80:34:03:88:AE:A5 90:FA:98:D6:46:DD:5F:00:60:2D:68:D1:7D:D7:6B:55:EE:51:CD:A3:D3:92:2F:0D:BD:D1:04:80:F5:99:0A:CD FE:BF:42:F9:BE:5A:BF:DD:B8:17:5D:01:02:39:F9:03:6F:E9:0D:33:3E:70:8E:13:CC:5E:ED:FF:D5:2D:0A:97 https://cert.webtrust.org/SealFile?seal=2253&file=pdf SHA-256 Fingerprints of certs in scope of audit: 30:CE:40:96:31:12:0A:0C:5A:C5:48:AB:FB:23:17:89:A8:47:41:1C:38:18:A5:6E:9B:06:FE:B1:72:3C:E7:97 1F:99:2B:63:59:05:FC:0E:EC:ED:AA:BC:EA:F9:74:1D:77:77:8D:D8:38:DE:92:B5:BB:51:11:72:2F:46:31:D6 Taiwan GRCA must provide current audit statements (included BR audit statements) for all of their subCAs annually, and must keep the data in the CCADB current. If a subCA does not issue TLS/SSL certs, then that subCA may be added to OneCRL to remove the requirement of having an annual BR audit statement. > > The newest statement I could find about BR compliance was in response to the > May 2014 communication - > https://docs.google.com/spreadsheets/d/1v- > Lrxo6mYlyrEli_wSpLsHZvV5dJ_vvSzLTAMfxI5n8/pubhtml - suggesting that GRCA > expected an audit to be completed within the year. > > From looking at the original inclusion bug, GRCA acts as a "Super-CA" - > https://bugzilla.mozilla.org/show_bug.cgi?id=274106#c4 - but the audit > information provided to the CCADB does not seem to reflect that or be > consistent with this response (with respect to audit scope). Given > https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Super-CAs , I believe > it would be consistent with Mozilla's policies for inclusion to remove this > CA, but would be interested in your thinking. Super-CAs are allowed to be in Mozilla's program if they continuously ensure that all of their subCAs are meeting the requirements of Mozilla's Root Store Policy and the CA/Browser Forum's Baseline Requirements. If the Taiwan GRCA is unable to keep their full CA hierarchy in full compliance of our requirements, then we should remove the root (Super-CA) cert, and only consider inclusion of specific subordinate CAs who do fully meet Mozilla's root store requirements. I will update Bug #1065896 to this effect as well.
Flags: needinfo?(kwilson)
Comment 6•7 years ago
|
||
(In reply to National Development Council from comment #3) > 1.How your CA first became aware of the problem (e.g. via a problem report > submitted to your Problem Reporting Mechanism, via a discussion in > mozilla.dev.security.policy, or via a Bugzilla bug), and the date. > -->Via Bugzilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=1397832 at > Sep. 23 2017 An email about this was sent to you by Kathleen when she filed the bug (at least, she tells me she emailed all the affected CAs). Did you not receive this email? Kathleen: can you check that it was sent, and let us know who it was sent to? Gerv
Flags: needinfo?(kwilson)
Comment 7•7 years ago
|
||
(In reply to Gervase Markham [:gerv] from comment #6) > Kathleen: can you check that it was sent, and let us know who it > was sent to? Here are the emails that I sent... -------- Forwarded Message -------- Subject: URGENT: Need your response in Bugzilla #1397832 Date: Fri, 8 Sep 2017 11:54:11 -0700 From: Kathleen Wilson <kwilson@mozilla.com> To: 徐宏宇 <horn917@cht.com.tw>, 政府處 吳三裕 <robbetwu@cht.com.tw> Hello Hong-Yu Hsu and Rob Betwu, An incident regarding your CA has been reported, and it has been determined that the problem can cause active issuance (via SHA-1 collisions) of trusted certs. Therefore, your prompt response in the following Bugzilla Bug is requested. https://bugzilla.mozilla.org/show_bug.cgi?id=1397832 I assigned the bug to gpki@ndc.gov.tw. If you need me to directly add you to the bug, then please create a Bugzilla account and send me the email for it: https://bugzilla.mozilla.org/createaccount.cgi Regards, Kathleen -------- Forwarded Message -------- Subject: Re: URGENT: Need your response in Bugzilla #1397832 Date: Fri, 22 Sep 2017 17:39:54 -0700 From: Kathleen Wilson <kwilson@mozilla.com> To: 徐宏宇 <horn917@cht.com.tw>, 政府處 吳三裕 <robbetwu@cht.com.tw> CC: gpki <gpki@ndc.gov.tw>, Gervase Markham <gerv@mozilla.org>, Aaron Wu <awu@mozilla.com> Dear Government of Taiwan CA, A representative of your CA must respond immediately in https://bugzilla.mozilla.org/show_bug.cgi?id=1397832 Regards, Kathleen
Flags: needinfo?(kwilson)
Assignee | ||
Comment 8•7 years ago
|
||
Provide the latest Audit reports for all subCAs . GRCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/GRCA_Audit_Report_2017.pdf) GCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/GCA_WTCA_Report_2017.pdf) GCA BR (http://grca.nat.gov.tw/download/Audit/GCA_BR_Audit_Report_2017.pdf) XCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/XCA_Audit_Report_2017.pdf) HCA WebTrust CA (http://grca.nat.gov.tw/download/Audit/HCA_WTCA_Audit_Report_2016.pdf) HCA BR (http://grca.nat.gov.tw/download/Audit/HCA_BR_Audit_Report_2016.pdf) MOEACA WebTrust CA (http://grca.nat.gov.tw/download/Audit/MOEACA_Audit_Report_2017.pdf) MOICA WebTrust CA (http://grca.nat.gov.tw/download/Audit/MOICA_Audit_Report_2017.pdf) The annual audit for HCA just finished. we don't get the audit report yet.
Comment 9•7 years ago
|
||
National Development Council: you need to provide current audit information in the CCADB, not just in this bug here. Has that been done? Please also reply to the issues raised in comment #6 and comment #4 ASAP. Gerv
Assignee | ||
Comment 10•7 years ago
|
||
(In reply to Gervase Markham [:gerv] from comment #6) > (In reply to National Development Council from comment #3) > > 1.How your CA first became aware of the problem (e.g. via a problem report > > submitted to your Problem Reporting Mechanism, via a discussion in > > mozilla.dev.security.policy, or via a Bugzilla bug), and the date. > > -->Via Bugzilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=1397832 at > > Sep. 23 2017 > > An email about this was sent to you by Kathleen when she filed the bug (at > least, she tells me she emailed all the affected CAs). Did you not receive > this email? Kathleen: can you check that it was sent, and let us know who it > was sent to? > > Gerv After some investigation, I found the Sep. 8 email in spam mail box. It never happen before, and I have changed the detection rule to prevent the mail goes to spam mail box again. I would also like to provide an extra email address horn917@gmail.com as a backup email address.
Assignee | ||
Comment 11•7 years ago
|
||
(In reply to Ryan Sleevi from comment #4) > (In reply to National Development Council from comment #3) > > 2.A timeline of the actions your CA took in response. > > -->Sep. 23: Identify the incident and found that HCA (one of subordinate CA) > > misunderstood the policy. > > Sep. 24: Contact the subordinate CA administrator and scheduled to fix > > the problem before Sep. 27. > > Sep. 25: Confirm that no other subordinate CA has the same issue. > > Sep. 30: Confirm the problem were fixed and report to bugzilla. > > Can you also please provide the timeline related to compliance steps taken? > > Such as, when did GRCA first update its policies with respect to the BR > change, when did GRCA notify its subordinates of the policy change, were > there any other policies or practices GRCA had in place for compliance > changes that were followed? 5 Apr. 2017 Received Mozilla April 2017 CA communication. 12 Apr. 2017 Notify all subordinate CAs to check the compliance of CA communication. 25 Apr. 2017 Received reports from all subordinate CAs (including HCA) and confirm the result of all subordinate CAs. 28 Apr. 2017 Report results to CCADB 7 Sep. 2017 This problem were notified on Bugzilla (Bug 1397832) HCA not only issues SSL certificates (not issued since Sep. 2016), but also other certificates. Considering the OCSP related to API and interoperability to the legacy system, HCA can’t stop generating SHA-1 OCSP response immediately. In the mean time, HCA misunderstands the SHA-1 deprecation policy and just stops issues the SHA-1 certificates. That’s why HCA reports to GRCA that they have done with the SHA-1 deprecation. Through this notification, GRCA required HCA to stop generating SHA-1 OCSP response immediately, and HCA stops generating SHA-1 OCSP response at 30 Sep. 2017. GRCA and all subordinate CAs have regular meeting with Government Electronic Certification Steering Committee (twice per year). If necessary GRCA also have meetings with subordinate CAs and make the subordinate CAs to comply with related requirement. > > > 7.List of steps your CA is taking to resolve the situation and ensure such > > issuance will not be repeated in the future, accompanied with a timeline of > > when your CA expects to accomplish these things. > > -->In order to prevent from subordinate CAs misunderstanding the new > > policies, GRCA will take following steps when policies change: > > 1.Gathering all subordinate CAs and explain new policies precisely. > > 2.Get the schedule of subordinate CAs to conform new policies. > > 3.Technically review all subordinate CAs and check completeness. > > These action takes effect immediately. > > Approximately how many independent sub-CAs does GRCA have? The subordinate certification authorities under GRCA are: 1.Government Certification Authority(GCA), 2.miXed organization Certification Authority(XCA), 3.Certification Authority of MOI(MOICA), 4.Certification Authority of MOEA(MOEACA), 5.Healthcare Certification Authority (HCA). Only GCA and HCA issues SSL certificates. P.S HCA no longer issues SSL certificate since Sep. 2016 > Kathleen: From trying to examine the audit information (based on both crt.sh > and > https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport ), > I cannot appear to find a BR audit for these CAs (e.g. > https://crt.sh/?id=12714631 or https://crt.sh/?id=12721379 ) > > The newest statement I could find about BR compliance was in response to the > May 2014 communication - > https://docs.google.com/spreadsheets/d/1v- > Lrxo6mYlyrEli_wSpLsHZvV5dJ_vvSzLTAMfxI5n8/pubhtml - suggesting that GRCA > expected an audit to be completed within the year. GRCA has 5 subordinate CAs, including GCA, XCA, MOICA, MOEACA and HCA. Only GCA and HCA (HCA no longer issues SSL certificate since Sep. 2016) issue SSL certificates, and we have baseline requirement audit reports for both GCA and HCA. The baseline requirement audit also applied to GRCA. Since GRCA does not issues any SSL certificates, we don’t have a separated audit report for it. Instead of providing the audit report, we provide an audit statement that states how the baseline requirement audits are performed according to Kathleen’s suggestion(https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/eFG27ZTYWD8/WleX5FSHEQAJ 16/12/14). The audit statement is available at https://bug1065896.bmoattachments.org/attachment.cgi?id=8835815(2016’s version. The 2017’s will be available in Nov. 2017). The auditors, KPMG are willing to explain the audit process if necessary.The contact information for the people at KPMG is below: David Hsiu 68F, TAIPEI 101 TOWER, No.7, Sec. 5, Xinyi Road, Taipei 11049, Taiwan (R.O.C.) email: dhsiu@kpmg.com.tw T: +886 (2) 8101 6666 ext.11900 F: +886 (2) 8101 6667 ext.11900 > From looking at the original inclusion bug, GRCA acts as a "Super-CA" - > https://bugzilla.mozilla.org/show_bug.cgi?id=274106#c4 - but the audit > information provided to the CCADB does not seem to reflect that or be > consistent with this response (with respect to audit scope). Given > https://wiki.mozilla.org/CA/Subordinate_CA_Checklist#Super-CAs , I believe > it would be consistent with Mozilla's policies for inclusion to remove this > CA, but would be interested in your thinking.
Reporter | ||
Comment 12•7 years ago
|
||
I've confirmed that this responder is no longer signing responses with SHA-1. Can this bug be made public now?
Updated•7 years ago
|
Blocks: BR-Compliance
Whiteboard: [ca-compliance]
Updated•7 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Updated•2 years ago
|
Product: NSS → CA Program
Updated•2 years ago
|
Whiteboard: [ca-compliance] → [ca-compliance] [ocsp-failure]
You need to log in
before you can comment on or make changes to this bug.
Description
•