Re: Removal of 1024 bit CA roots - interoperability
On 05/08/14 09:34, Rob Stradling wrote: Kathleen, to work around the classic NSS path building behaviour you observed yesterday, we will issue another cross-certificate to USERTrust Legacy Secure Server CA, with a newer notBefore date, from our AddTrust External CA Root built-in root. Then, you can include this new cross-certificate in NSS instead of the one issued by the 2048-bit Entrust built-in root. We'll pull out all the stops and get this new cross-certificate issued today. Kai, just in case you were planning to tag NSS 3.16.4 within the next few hours...please wait, if you can. :-) We've issued this new cross-certificate and I've attached it to bug 1045189. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removal of 1024 bit CA roots - interoperability
- Original Message - From: Kurt Roeckx k...@roeckx.be To: Hubert Kario hka...@redhat.com Cc: Kathleen Wilson kwil...@mozilla.com, mozilla-dev-security-pol...@lists.mozilla.org Sent: Tuesday, August 5, 2014 12:44:13 AM Subject: Re: Removal of 1024 bit CA roots - interoperability On Mon, Aug 04, 2014 at 10:03:13AM -0400, Hubert Kario wrote: So I've analysed the data. Change (without-with) Count -+- complete -219 incomplete+120 untrusted +99 So this is in the order of 0.05% of the sites that would break? I'm happy to ignore that and just do it. 0.05% of sites doesn't mean 0.05% of users, especially if we look at local, not global, user share. Some of them are high profile sites, e.g.: volkswagen.at, dell.com, cadillaceurope.com, www.portaldasfinancas.gov.pt -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removal of 1024 bit CA roots - interoperability
On 2014-08-05 14:22, Hubert Kario wrote: 0.05% of sites doesn't mean 0.05% of users, especially if we look at local, not global, user share. Some of them are high profile sites, e.g.: volkswagen.at, dell.com, cadillaceurope.com, www.portaldasfinancas.gov.pt It's not because they have an https site that people actually use it over https. so testing those sites: - dell.com: Doesn't work without www. It's not mentioned in your other mail, but dell.cl and dell.com.br are. They all send the same certificate, and that's not valid for those hostnames. - cadillaceurope.com: it's not valid without www. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removal of 1024 bit CA roots - interoperability
- Original Message - From: Hubert Kario hka...@redhat.com - Original Message - From: Kathleen Wilson kwil...@mozilla.com == For this batch of root changes == We are still investigating if we should use this possible solution for this batch of root changes. Please stay tuned and continue to share data and test results that should be considered. So I've analysed the data. I simulated removal of 11 roots mentioned in bugs linked to https://bugzilla.mozilla.org/show_bug.cgi?id=1021967: Entrust.net Secure Server Certification Authority 99:A6:9B:E6:1A:FE:88:6B:4D:2B:82:00:7C:B8:54:FC:31:7E:15:39 GTE CyberTrust Global Root 97:81:79:50:D8:1C:96:70:CC:34:D8:09:CF:79:44:31:36:7E:F4:74 ValiCert Class 1 Policy Validation Authority E5:DF:74:3C:B6:01:C4:9B:98:43:DC:AB:8C:E8:6A:81:10:9F:E4:8E ValiCert Class 2 Policy Validation Authority 31:7A:2A:D0:7F:2B:33:5E:F5:A1:C3:4E:4B:57:E8:B7:D8:F1:FC:A6 ValiCert Class 3 Policy Validation Authority 69:BD:8C:F4:9C:D3:00:FB:59:2E:17:93:CA:55:6A:F3:EC:AA:35:FB NetLock Uzleti (Class B) Tanusitvanykiado 87:9F:4B:EE:05:DF:98:58:3B:E3:60:D6:33:E7:0D:3F:FE:98:71:AF NetLock Uzleti (Class C) Tanusitvanykiado E3:92:51:2F:0A:CF:F5:05:DF:F6:DE:06:7F:75:37:E1:65:EA:57:4B VeriSign, Inc. / Class 3 Public Primary Certification Authority A1:DB:63:93:91:6F:17:E4:18:55:09:40:04:15:C7:02:40:B0:AE:6B 74:2C:31:92:E6:07:E4:24:EB:45:49:54:2B:E1:BB:C5:3E:61:74:E2 Sociedad Cameral de Certificacion Digital CB:A1:C5:F8:B0:E3:5E:B8:B9:45:12:D3:F9:34:A2:E9:06:10:D3:36 TDC Internet Root CA 21:FC:BD:8E:7F:6C:AF:05:1B:D1:B3:43:EC:A8:E7:61:47:F2:0F:8A The data (and as such, the certificates) were collected between 11th and 19th of July 2014 and did include Alexa top 1 million domain names as of 10th of July. With the above certificates: Server provided chainsCount Percent -+-+--- complete 35948461.6908 incomplete29543 5.0699 untrusted 19369233.2393 Without the above certificates: Server provided chainsCount Percent -+-+--- complete 35926561.6532 incomplete29663 5.0904 untrusted 19379133.2563 Change (without-with) Count -+- complete -219 incomplete+120 untrusted +99 Attached are the lists of those servers. (disclaimer: trust chain building did ignore host names, extended key usage limitations, and used OpenSSL for chain building) I've also gathered a bit extra statistics. The use of key sizes in CA certificates (count is number of chains that use them): With the 1024 bit roots: Chains with CA keyCount Percent -+-+--- ECDSA 256 2 0.0004 ECDSA 384 2 0.0004 RSA 1024 1776 0.399 RSA 2045 1 0.0002 RSA 2048 44339999.619 RSA 4096 16134 3.6248 Without the 1024 bit roots: Chains with CA keyCount Percent -+-+--- ECDSA 256 2 0.0004 ECDSA 384 2 0.0004 RSA 1024 1539 0.3459 RSA 2045 1 0.0002 RSA 2048 44330899.6229 RSA 4096 16121 3.6228 it has limited effect on overall security of connection (if we assume 80 bit level of security for both SHA1 and 1024 bit RSA and ignore signature algorithm on the root certs): With weak roots: Eff. host cert chain LoS Count Percent -+-+--- 8039841389.5119 112 46680 10.4876 128 2 0.0004 Without weak roots: Eff. host cert chain LoS Count Percent -+-+--- 8039830489.5093 112 46680 10.4902 128 2 0.0004 -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removal of 1024 bit CA roots - interoperability
Hubert, what's your conclusion of your analysis? Thanks Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removal of 1024 bit CA roots - interoperability
On Mon, Aug 04, 2014 at 10:03:13AM -0400, Hubert Kario wrote: So I've analysed the data. Change (without-with) Count -+- complete -219 incomplete+120 untrusted +99 So this is in the order of 0.05% of the sites that would break? I'm happy to ignore that and just do it. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removal of 1024 bit CA roots - interoperability
On 7/31/14, 1:17 PM, Kathleen Wilson wrote: Here's what we are doing for this first batch of root changes that was made in NSS 3.16.3, and is currently in Firefox 32, which is in Beta. NSS 3.16.4 will be created and included in Firefox 32. It will only contain these two changes: 1) https://bugzilla.mozilla.org/show_bug.cgi?id=1045189 -- Add the 2048-bit version of the USERTrust Legacy Secure Server CA intermediate cert to NSS, this intermediate cert expires in November 2015. It turns out that including the 2048-bit version of the cross-signed intermediate certificate does not help NSS at all. It would only help Firefox, and would cause confusion. https://bugzilla.mozilla.org/show_bug.cgi?id=1045189#c13 -- old intermediate: Subject: CN=USERTrust Legacy Secure Server CA,O=The USERTRUST Network,L=Salt Lake City,ST=UT,C=US Issuer: CN=Entrust.net Secure Server Certification Authority,OU=(c) 1999 Entrust.net Limited,OU=www.entrust.net/CPS incorp. by ref. (limits liab.),O=Entrust.net,C=US Serial Number: 1184831531 (0x469f182b) Validity: Not Before: Thu Nov 26 20:33:13 2009 Not After : Sun Nov 01 04:00:00 2015 the replacement intermediate:: Subject: CN=USERTrust Legacy Secure Server CA,O=The USERTRUST Network,L=Salt Lake City,ST=UT,C=US Issuer: CN=Entrust.net Certification Authority (2048),OU=(c) 1999 Entrust.net Limited,OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.),O=Entrust.net Serial Number: 946071786 (0x3863e8ea) Validity: Not Before: Thu Nov 26 20:05:16 2009 Not After : Sun Nov 01 05:00:00 2015 When given the choice of the above two certificates for chaining, which use an identical subject, the legacy NSS chaining code will try only one path. It will decide which certificate to use based on the validity time/date. It will pick the one that looks newer. Unfortunately, the time/date of the certificates don't indicate a clear winner. -- Kai tested this adding the 2048-bit intermediate cert to NSS, and found that the 1024-bit intermediate cert was still used. It works for Firefox, because mozilla::pkix keeps trying until it finds a certificate path that works. Therefore, it looks like including the 2048-bit intermediate cert directly in NSS would cause different behavior depending on where the root store is being used. This would lead to confusion. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removal of 1024 bit CA roots - interoperability
On Mon, Aug 4, 2014 at 3:52 PM, Kathleen Wilson kwil...@mozilla.com wrote: It turns out that including the 2048-bit version of the cross-signed intermediate certificate does not help NSS at all. It would only help Firefox, and would cause confusion. That isn't true, AFAICT. It works for Firefox, because mozilla::pkix keeps trying until it finds a certificate path that works. NSS's libpkix also keeps trying until if finds a certificate path that works. libpkix is used by Chromium and by Oracle's products (IIUC). Therefore, it looks like including the 2048-bit intermediate cert directly in NSS would cause different behavior depending on where the root store is being used. This would lead to confusion. IMO, it isn't reasonable to make decisions like this based on the behavior of the classic NSS path building. Really, the classic NSS path building logic is obsolete, and anybody still using it is going to have lots of compatibility problems due to this change and other things, some of which are out of our control. Cheers, Brian ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removal of 1024 bit CA roots - interoperability
Hubert Kario hka...@redhat.com wrote: Brian Smith wrote: It depends on your definition of help. I assume the goal is to encourage websites to migrate from 1024-bit signatures to RSA-2048-bit or ECDSA-P-256 signatures. If so, then including the intermediates in NSS so that all NSS-based applications can use them will be counterproductive to the goal, because when the system administrator is testing his server using those other NSS-based tools, he will not notice that he is depending on 1024-bit certificates (cross-signed or root) because everything will work fine. The point is not to ship a 1024 bit cert, the point is to ship a 2048 bit cert. So for sites that present a chain like this: 2048 bit host cert - 2048 bit old sub CA - 1024 bit root CA we can find a certificate chain like this: 2048 bit host cert - 2048 bit new cross-signed sub CA - 2048 bit root CA where the cross-signed sub CA is shipped by NSS Sure. I have no objection to including cross-signing certificates where both the subject public key and the issuer public key are 2048 bits (or more). I am objecting only to including any cross-signing certificates of the 1024-bit-subject-signed-by-2048-bit-issuer variety. It has been a long time since we had the initial conversation, but IIRC both types of cross-signing certificates exist. Cheers, Brian ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removal of 1024 bit CA roots - interoperability
On 7/25/14, 3:11 PM, Kathleen Wilson wrote: == Background == We have begun removal of 1024-bit roots with the following 2 bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=936304 -- Remove Entrust.net, GTE CyberTrust, and ValiCert 1024-bit root certificates from NSS https://bugzilla.mozilla.org/show_bug.cgi?id=986005 -- Turn off SSL and Code Signing trust bits for VeriSign 1024-bit roots There are two more sets of 1024-bit root changes that will need to follow: https://bugzilla.mozilla.org/show_bug.cgi?id=986014 -- Remove Thawte 1024-bit roots https://bugzilla.mozilla.org/show_bug.cgi?id=986019 -- Turn off SSL and Code Signing trust bits for Equifax 1024-bit roots == Problem == Some web server administrators have not updated their web servers to provide a new intermediate certificate signed by a newer root, even though the CA has implored them to do so. For those websites, users may get the Untrusted Connection error when the old root is removed. == For this batch of root changes == We are still investigating if we should use this possible solution for this batch of root changes. Please stay tuned and continue to share data and test results that should be considered. Here's what we are doing for this first batch of root changes that was made in NSS 3.16.3, and is currently in Firefox 32, which is in Beta. NSS 3.16.4 will be created and included in Firefox 32. It will only contain these two changes: 1) https://bugzilla.mozilla.org/show_bug.cgi?id=1045189 -- Add the 2048-bit version of the USERTrust Legacy Secure Server CA intermediate cert to NSS, this intermediate cert expires in November 2015. 2) https://bugzilla.mozilla.org/show_bug.cgi?id=1046343 -- Backout removal of the 1024-bit GTE CyberTrust Global Root I have filed another bug to make a new plan for migration off of the 1024-bit GTE CyberTrust Global Root, and then remove it. https://bugzilla.mozilla.org/show_bug.cgi?id=1047011 Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Removal of 1024 bit CA roots - interoperability
Ultimately, AIA chaining, scoring of TLS payload over NSS saved CAs in path discovery, and a purge of passively discovered intermediates chaining to the subject roots from NSS would create a permanent way forward. Unless these are feasible, we'll keep feeding intermediate certs signed under our go forward roots that were in use under our retiring root. In the vast majority of cases, our customers did not cross-sign into our go forward roots, they created new subordinate PKIs and we signed new requests. It is common for our customers to operate multiple concurrent intermediates. It is common for our customers to use a PKI product that has no licensing burden in creating CAs and certs, only the licensing of our public trust enablement. Therefore they don't need to cross-sign to save cost. In our own PKIs that drive our SaaS applications, we never cross-sign intermediates or issuers across roots, we always bootstrap new chains. We may cross-sign at the root tier for ubiquity crutches. Kind regards, Steven Medin Product Manager, Identity and Access Management Verizon Enterprise Solutions -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+steve.medin=verizonbusiness@lists.mo zilla.org] On Behalf Of Kathleen Wilson Sent: Monday, July 28, 2014 4:29 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Removal of 1024 bit CA roots - interoperability On 7/25/14, 3:11 PM, Kathleen Wilson wrote: On 7/4/14, 6:27 AM, Hubert Kario wrote: The newly released NSS 3.16.3 doesn't include 1024 bit CA certificates any more[1]. This will of course impact users of servers that still use it. snip That's why I think that we should ship the intermediate CA certificates to make Firefox continue to interoperate with such sites. snip == For this batch of root changes == We are still investigating if we should use this possible solution for this batch of root changes. Please stay tuned and continue to share data and test results that should be considered. I have filed a bug regarding this: https://bugzilla.mozilla.org/show_bug.cgi?id=1045189 Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Removal of 1024 bit CA roots - interoperability
The newly released NSS 3.16.3 doesn't include 1024 bit CA certificates any more[1]. This will of course impact users of servers that still use it. Interestingly, some intermediate CA certificates that were originally signed by those 1024 bit CA certificates got cross signed using different roots that will remain trusted[2]. In particular I mean the USERTrust Legacy Secure Server CA certificate. Problem is, that some administrators haven't updated their servers to provide the new intermediate certificate for 3 years. As such, I don't think we can realistically expect all of them to update their configuration now. While testing found just 217 sites as of 2014-05-30 that are impacted by this change[2], it did test only top 200 000 SSL enabled servers. I'd estimate the total number in Alexa top 1M alone at over 373k. Moreover, some of those sites include sites that are in the top 1 sites, like groupon.my[3]. So loss of connectivity to them may have bigger impact than the above quoted 217 could lead us to believe. That's why I think that we should ship the intermediate CA certificates to make Firefox continue to interoperate with such sites. I don't mean only the USERTrust certificate, but others too, if they exist. 1 - https://bugzilla.mozilla.org/show_bug.cgi?id=1021967 2 - https://bugzilla.mozilla.org/show_bug.cgi?id=936304 3 - https://www.ssllabs.com/ssltest/analyze.html?d=groupon.my -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removal of 1024 bit CA roots - interoperability
On Fri, Jul 04, 2014 at 09:27:49AM -0400, Hubert Kario wrote: The newly released NSS 3.16.3 doesn't include 1024 bit CA certificates any more[1]. This will of course impact users of servers that still use it. Interestingly, some intermediate CA certificates that were originally signed by those 1024 bit CA certificates got cross signed using different roots that will remain trusted[2]. In particular I mean the USERTrust Legacy Secure Server CA certificate. Not sure which certificte you mean with that. Problem is, that some administrators haven't updated their servers to provide the new intermediate certificate for 3 years. As such, I don't think we can realistically expect all of them to update their configuration now. While testing found just 217 sites as of 2014-05-30 that are impacted by this change[2], it did test only top 200 000 SSL enabled servers. I'd estimate the total number in Alexa top 1M alone at over 373k. Moreover, some of those sites include sites that are in the top 1 sites, like groupon.my[3]. So loss of connectivity to them may have bigger impact than the above quoted 217 could lead us to believe. Using Rapid7's Solar data from 30 june 2014, I see those certificates that many times: 99a69be61afe886b4d2b82007cb854fc317e153911204 97817950d81c9670cc34d809cf794431367ef47419815 e5df743cb601c49b9843dcab8ce86a81109fe48e7 317a2ad07f2b335ef5a1c34e4b57e8b7d8f1fca689707 69bd8cf49cd300fb592e1793ca556af3ecaa35fb116 That's why I think that we should ship the intermediate CA certificates to make Firefox continue to interoperate with such sites. Is it an option to instead ship the intermediate so that we find an alternative trust path? We might already pick up that alternative in most cases. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removal of 1024 bit CA roots - interoperability
Hubert Kario hka...@redhat.com writes: Problem is, that some administrators haven't updated their servers to provide the new intermediate certificate for 3 years. As such, I don't think we can realistically expect all of them to update their configuration now. That is not surprising. IME the vendors do not announce the new intermediates to their customers. (Some might, but some definitely do not.) -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
