Closed Bug 1214321 Opened 9 years ago Closed 8 years ago

Add Symantec Test Certs to OneCRL

Categories

(Core :: Security: PSM, defect)

Product:
Core
Component:
Security: PSM
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: kathleen.a.wilson, Assigned: mgoodwin)

References

Details

Attachments

(7 files)

OneCRL 2015-11-06.csv
33.55 KB, application/vnd.ms-excel
Details
OneCRL EV Only 2015-11-19.csv
4.33 KB, application/vnd.ms-excel
Details
serial-issuer-pairs.csv
9.39 KB, text/plain
Details
Test_Certificates_Incident_Final_Report.pdf
147.18 KB, application/pdf
Details
Test_Certificates_Incident_Final_Report_10_12_2015.pdf
184.68 KB, application/pdf
Details
Test_Certificates_Incident_Final_Report_10_13_2015v3.pdf
195.94 KB, application/pdf
Details
TestCertificateIncidentReportOwnedDomains.pdf
1.12 MB, application/pdf
Details 
Symantec has provided a list of test certificates that they mis-issued for domains that are registered to third parties.

https://www-secure.symantec.com/connect/sites/default/files/TestCertificateIncidentReportOwnedDomains.pdf

There are 164 certificates in the list. We should add these certificates to OneCRL.
Further discussion about this event will happen here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/Hkyg_09EDYE/kzQAK3mqAwAJ
Symantec, Please list the URLs to the CRLs containing these revocations.
Here's the CRL names and URL in CSV format:

Equifax Secure Certificate Authority,crl.geotrust.com/crls/secureca.crl 
GeoTrust DSA SSL CA,gi.symcb.com/gi.crl
GeoTrust DV SSL CA,gg.symcb.com/gg.crl
GeoTrust DV SSL CA - G2,gc.symcb.com/gc.crl
GeoTrust DV SSL CA - G3,gt.symcb.com/gt.crl
GeoTrust DV SSL CA - G4,gu.symcb.com/gu.crl
GeoTrust DV SSL SHA256 CA,gr.symcb.com/gr.crl
GeoTrust DV SSL SHA256 CA - G2,gy.symcb.com/gy.crl
GeoTrust EV SSL CA - G4,gm.symcb.com/gm.crl
GeoTrust Extended Validation SSL CA,ge.symcb.com/ge.crl
GeoTrust Extended Validation SSL CA - G2,ga.symcb.com/ga.crl
GeoTrust SHA256 SSL CA,gj.symcb.com/gj.crl
GeoTrust SSL CA,gf.symcb.com/gf.crl
GeoTrust SSL CA - G2,gb.symcb.com/gb.crl
GeoTrust SSL CA - G3,gn.symcb.com/gn.crl
RapidSSL CA,gh.symcb.com/gh.crl
RapidSSL SHA256 CA - G3,gv.symcb.com/gv.crl
RapidSSL SHA256 CA - G4,gz.symcb.com/gz.crl
Symantec Class 3 DSA EV SSL CA,sp.symcb.com/sp.crl
Symantec Class 3 DSA SSL CA,so.symcb.com/so.crl
Symantec Class 3 ECC 256 bit EV CA - G2,rd.symcb.com/rd.crl
Symantec Class 3 ECC 256 bit Extended Validation CA,sn.symcb.com/sn.crl
Symantec Class 3 ECC 256 bit SSL CA,sm.symcb.com/sm.crl
Symantec Class 3 ECC 256 bit SSL CA - G2,rc.symcb.com/rc.crl
Symantec Class 3 EV SSL CA - G2,st.symcb.com/st.crl
Symantec Class 3 EV SSL CA - G3,sr.symcb.com/sr.crl
Symantec Class 3 EV SSL SGC CA - G2,su.symcb.com/su.crl
Symantec Class 3 Secure Server CA - G4,ss.symcb.com/ss.crl
Symantec Class 3 Secure Server SHA256 SSL CA,sg.symcb.com/sg.crl
thawte DSA SSL CA,te.symcb.com/te.crl
Thawte DV SSL CA,tc.symcb.com/tc.crl
thawte DV SSL CA - G2,tn.symcb.com/tn.crl
thawte DV SSL SHA256 CA,tm.symcb.com/tm.crl
thawte EV SSL CA - G3,ti.symcb.com/ti.crl
thawte Extended Validation SHA256 SSL CA,tf.symcb.com/tf.crl
thawte Extended Validation SSL CA,ta.symcb.com/ta.crl
Thawte Premium Server CA,crl.thawte.com/ThawtePremiumServerCA.crl 
Thawte SGC CA,crl.thawte.com/ThawteSGCCA.crl 
Thawte SGC CA - G2,td.symcb.com/td.crl
thawte SHA256 SSL CA,tg.symcb.com/tg.crl
Thawte SSL CA,tb.symcb.com/tb.crl
thawte SSL CA - G2,tj.symcb.com/tj.crl
VeriSign Class 3 Extended Validation CA - T1,si.symcb.com/si.crl
VeriSign Class 3 Extended Validation SGC CA - T1,sj.symcb.com/sj.crl
VeriSign Class 3 Extended Validation SSL CA,sa.symcb.com/sa.crl 
VeriSign Class 3 Extended Validation SSL SGC CA,sb.symcb.com/sb.crl
VeriSign Class 3 International Server CA - G3,se.symcb.com/se.crl
VeriSign Class 3 Secure Server CA,crl.verisign.com/SVRSecure2005.crl 
VeriSign Class 3 Secure Server CA - G2,crl.verisign.com/SVRSecureG2.crl 
VeriSign Class 3 Secure Server CA - G3,sd.symcb.com/sd.crl
VeriSign Class 3 Secure Server CA - T1,sk.symcb.com/sk.crl
VeriSign International Server CA - Class 3,crl.verisign.com/SVRIntl.crl
Hi Rick,

As we have an open communication channel in this bug: a couple of good questions have been raised in the public discussion.

1) This list of test certs for owned domains contains an entry for
a cert with serial number 0xc222a issued by RapidSSL CA, valid from 05/18/2013
22:27:16 GMT to 06/20/2015 13:57:13 GMT (last entry of the owned domains PDF).
This appears to be this certificate https://crt.sh/?id=1990400 which has:

            X509v3 Subject Alternative Name:
                DNS:*.icns.com.au
                DNS:icns.com.au

As of this writing, there appears to be a functional server at that
www.icns.com.au which presents that (expired and revoked) cert and to which
openssl s_client can successfully connect.

Is this entry an error? This cert does not look like the other testing certs I have examined.

2) In Symantec's initial incident report, you indicated 'the private keys
associated with the test certificates were all destroyed as part of the testing
tool that was used to enroll for the test certificates'. Are you still making
this claim for the test certificates found subsequently?

Thanks,

Gerv
Gerv, we're investigating. I'll update this bug as soon as I have more info.
Let's keep this bug devoted to OneCRL.

For further questions and answers about this incident, let's use the discussion in m.d.s.policy:
https://groups.google.com/d/msg/mozilla.dev.security.policy/Hkyg_09EDYE/kzQAK3mqAwAJ

Mark, Do you need any further data in order to make the changes to OneCRL?

Thanks.
(In reply to Kathleen Wilson from comment #6)
> Let's keep this bug devoted to OneCRL.

Rick: are you happy to engage with questions in m.d.s.policy or would you prefer another bug or some other mechanism where I filter the questions that are asked?

Gerv
Gerv, yes, we'd prefer to answer questions in m.d.s.policy.
Cool. You can see the 2 Qs above in there; I look forward to reading your answers :-)

Gerv
(In reply to Kathleen Wilson from comment #0)
> Symantec has provided a list of test certificates that they mis-issued for
> domains that are registered to third parties.
> 
> https://www-secure.symantec.com/connect/sites/default/files/
> TestCertificateIncidentReportOwnedDomains.pdf
> 
> There are 164 certificates in the list. We should add these certificates to
> OneCRL.

Rick, Are all of the certs in the list EV?
The reason I ask is that if they are EV, then the OCSP check will hard-fail due to the revocation, so we would not need to add those to OneCRL.
It has also been pointed out to me that the expired certs don't need to be added to OneCRL either.
Kathleen, not all the certs are EV, and some are also expired. We are continuing to collate all feedback and will be publishing an update soon that you can use to update your OneCRL. Thanks.
We have posted an update to our test certificate incident report at https://www-secure.symantec.com/connect/sites/default/files/Test_Certificates_Incident_Final_Report_20151029.pdf. That contains links to these updated files:

List of Test Certs of Owned Domains (Updated October 27, 2015) https://www-secure.symantec.com/connect/sites/default/files/Test_Certificate_Incident_Report_Owned_Domains_20151027.pdf
List of Test Certs of Unregistered Domains (Updated October 27, 2015) https://www-secure.symantec.com/connect/sites/default/files/Test_Certificate_Incident_Report_Unregistered_20151027.pdf

In those files, you can clearly see which certs are EV, and the expiration date of each.
I think we should add to OneCRL the certs in the lists in Comment #13 that meet all of the following:
- not EV (so OCSP not enforced)
- valid beyond 2015
- marked as 3 (Domain not owned at time of issuance) and 4 (Domain owned at time of issuance) -- I'm assuming those notes mean that someone other than Symantec might own those domains. Rick, is that correct?
The criteria that we understand you want to use to populate OneCRL is as follows:
 1. Only certificates for domains that were owned by a party other than Symantec at time of issue
 2. Not yet expired certificates
 3. Not EV certificates

Based on this, here’s how to get that info out of the two lists:

From the list of “owned domains” select all certificates that meet the following criteria (there are 47 in total):
 1. The note field is blank
 2. The expire date is on or after Nov 1, 2015

From the list of “unregistered domains” select all certificates that meet the following criteria (there are 4 in total):
 1. The note field is exactly “4” (do not include “1,4” or “1,4,5” — these were false positives and were properly issued)
 2. The expire date is on or after Nov 1, 2015

For your convenience, we have attached a CSV file that includes only these 51 certificates. One correction to your prior post is that you should not include certificates with Note #3 (these were certificates whose domains we have determined were unowned at the time of issuance and were improperly classified as “owned domains”).
Attached file OneCRL 2015-11-06.csv — 

    
    

    
  
Actually, I think we want the EV certificates as well (for EV, OCSP is only "enforced" insofar as if a response can't be fetched, Firefox will fall back to DV validation, and if a response still can't be fetched, the connection succeeds, just with no EV indicator).

Also, I can't find the certificates indicated in attachment 8684462 [details] in any certificate transparency log. Rick, are those going to be disclosed?
Flags: needinfo?(rick_andrews)

    
    

    
  
(In reply to David Keeler [:keeler] (use needinfo?) from comment #17)
> Actually, I think we want the EV certificates as well (for EV, OCSP is only
> "enforced" insofar as if a response can't be fetched, Firefox will fall back
> to DV validation, and if a response still can't be fetched, the connection
> succeeds, just with no EV indicator).

David, I attached a csv file with the EV certs that were not expired as of November 1, 2015 and that were issued to owned domains. 

> Also, I can't find the certificates indicated in attachment 8684462 [details]
> [details] in any certificate transparency log. Rick, are those going to be
> disclosed?

We don’t have plans to log these certificates.
Flags: needinfo?(rick_andrews)

    
    

    
  
Rick, OneCRL wasn't really intended for typical end-entity cert revocations, so we don't want to just add a bunch of end-entity cert data to it, especially if the test certs were issued to *symantec*.com domain names. So, we would like the ability to evaluate which of these revoked test certs we should add to OneCRL. My understanding is that we can do that with the EV certs, because those EV certs are already available via CT. But we do not have sufficient information about the non-EV certs to make the decision about whether we should add them to OneCRL or not. So, would you please add a column to the .csv attachment to Comment #16 to provide the domain name(s) included in the cert? 
(I didn't see any way for us to find this information based on what has already been published.)

    
    

    
  
Kathleen, we’ve notified all of the owners of domains used for the relevant test certs we’ve identified. Some organizations have explicitly asked us to not disclose additional details; however, we can provide you with the domain info if we receive authorization to do so from the domain owners. At this point, Google and Opera are the only organizations who have indicated that they are OK with public disclosure.  I believe you know those specific certs, but we can follow up with those if needed.

    
    

    
  
(In reply to Rick Andrews from comment #21)
> Kathleen, we’ve notified all of the owners of domains used for the relevant
> test certs we’ve identified. Some organizations have explicitly asked us to
> not disclose additional details; 

In that case, would you please update the OneCRL attachment in Comment #16 to:
1) Remove any certs with only *symantec* domains.
2) Add cert expiration dates, so we can track when to remove them from OneCRL.

    
    

    
  
Kathleen, there's nothing to update. The attachment in Comment #16 included only certificates for domains that were owned by a party other than Symantec at time of issue; hence no *symantec* domains. And the csv file includes the cert expiration dates.

    
    

    
  
Symantec announced the results of their investigation:
http://www.symantec.com/connect/blogs/results-our-investigation_0

    
    

    
  
https://www.symantec.com/page.jsp?id=test-certs-update
 The certificate details are available here for reference, including certificates identified since our last report on October 29, 2015 which are identified in the column titled “Apr 2016”:
List of Mis-issued Test Certificates to Owned Domains (Updated April 21, 2016)
https://vs.symantec.com/assets/csv/test-certificate-incident-report-owned-domain-summary_april-2016.csv
List of Mis-issued Test Certificates to Unregistered Domains (Updated April 21, 2016)
https://vs.symantec.com/assets/csv/test-certificate-incident-report-unregistered-domain-summary_april-2016.csv

    
    

    
  


  
These are the encoded serial/issuer pairs of unexpired certificates from the owned domain list. Mark - can you make sure this makes it into OneCRL? Thanks.
Flags: needinfo?(mgoodwin)

    
    

    
  
(In reply to David Keeler [:keeler] (use needinfo?) from comment #26)
> Mark - can you make sure this makes it into OneCRL?
> Thanks.

Sure. I have filed bug 1267648 to track creation of AMO blocklist items. I will follow up once this is done to ensure the new blocklist items are being updated accordingly.
Flags: needinfo?(mgoodwin)

    
    

    
  
These items are now visible in the blocklist.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED

    
  
Blocks: onecrl-meta

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: