Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 11 users
Status: Verified
Owner:
Closed: Jan 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux, Android, Windows, Chrome, Mac
Pri: 3
Type: Bug


Show other hotlists

Hotlists containing this issue:
Hotlist-1


Sign in to add a comment
Restrict the set of domains for WoSign/StartCom certificates
Project Member Reported by rsleevi@chromium.org, Jan 26 2017 Back to list
As captured in https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html and reviewed by rahulrc@ and darin@

"In subsequent Chrome releases, these exceptions will be reduced and ultimately removed, culminating in the full distrust of these CAs. This staged approach is solely to ensure sites have the opportunity to transition to other Certificate Authorities that are still trusted in Google Chrome, thus minimizing disruption to users of these sites. Sites that find themselves on this whitelist will be able to request early removal once they’ve transitioned to new certificates. Any attempt by WoSign or StartCom to circumvent these controls will result in immediate and complete removal of trust."


 
Project Member Comment 1 by bugdroid1@chromium.org, Jan 27 2017
Labels: Merge-Request-57
Project Member Comment 3 by sheriffbot@chromium.org, Jan 27 2017
Labels: -Merge-Request-57 Hotlist-Merge-Approved Merge-Approved-57
Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member Comment 4 by bugdroid1@chromium.org, Jan 27 2017
Labels: -merge-approved-57 merge-merged-2987
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e719fc626a3b9a528bf226b704785bcb24d07868

commit e719fc626a3b9a528bf226b704785bcb24d07868
Author: Ryan Sleevi <rsleevi@chromium.org>
Date: Fri Jan 27 21:14:49 2017

Restrict the set of WoSign/StartCom certs to the Alexa Top 1M

Restrict the set of domains for which WoSign/StartCom certificates
are trusted to the set of domains intersecting the Alexa Top 1M
whose certificates are unexpired and unrevoked.

BUG= 685826 

Review-Url: https://codereview.chromium.org/2613833002
Cr-Commit-Position: refs/heads/master@{#446501}
(cherry picked from commit a4912183cbef2f2e76654467db74cf7d79b5052e)

Review-Url: https://codereview.chromium.org/2662673002 .
Cr-Commit-Position: refs/branch-heads/2987@{#153}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/e719fc626a3b9a528bf226b704785bcb24d07868/net/BUILD.gn
[modify] https://crrev.com/e719fc626a3b9a528bf226b704785bcb24d07868/net/cert/cert_verify_proc.cc
[modify] https://crrev.com/e719fc626a3b9a528bf226b704785bcb24d07868/net/cert/cert_verify_proc_whitelist.cc
[modify] https://crrev.com/e719fc626a3b9a528bf226b704785bcb24d07868/net/cert/cert_verify_proc_whitelist.h
[modify] https://crrev.com/e719fc626a3b9a528bf226b704785bcb24d07868/net/cert/cert_verify_proc_whitelist_unittest.cc
[add] https://crrev.com/e719fc626a3b9a528bf226b704785bcb24d07868/net/cert/cert_verify_proc_whitelist_unittest1.gperf
[add] https://crrev.com/e719fc626a3b9a528bf226b704785bcb24d07868/net/data/ssl/wosign/BUILD.gn
[add] https://crrev.com/e719fc626a3b9a528bf226b704785bcb24d07868/net/data/ssl/wosign/wosign_domains.gperf

Status: Verified
Before there was info that only certs issued after 21 October will be distrusted.
but yesterday my chrome updated and I found that bunch of my sites become broken in Chrome because of HSTS enabled.

There was announcment:
Beginning with Chrome 56, certificates issued by WoSign and StartCom after October 21, 2016 00:00:00 UTC will not be trusted.

Nothing about 1st million in Alexa.

My domains:
https://cloudzz.com/
https://nodeart.io/
https://wiki.nodeart.io/
https://*.nodeart.io/
https://*.stage.nodeart.io/

Just two sentences later:

Due to a number of technical limitations and concerns, Google Chrome is unable to trust all pre-existing certificates while ensuring our users are sufficiently protected from further misissuance. As a result of these changes, customers of WoSign and StartCom may find their certificates no longer work in Chrome 56.
In subsequent Chrome releases, these exceptions will be reduced and ultimately removed, culminating in the full distrust of these CAs. This staged approach is solely to ensure sites have the opportunity to transition to other Certificate Authorities that are still trusted in Google Chrome, thus minimizing disruption to users of these sites. Sites that find themselves on this whitelist will be able to request early removal once they’ve transitioned to new certificates. Any attempt by WoSign or StartCom to circumvent these controls will result in immediate and complete removal of trust.
Project Member Comment 8 by bugdroid1@chromium.org, Feb 28
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6fc397860ccafa55086456a4d1e6d713c418b41f

commit 6fc397860ccafa55086456a4d1e6d713c418b41f
Author: rsleevi <rsleevi@chromium.org>
Date: Tue Feb 28 01:56:02 2017

Reduce the set of WoSign/StartCom domains to the Alexa Top 500K

As part of phasing out trust in WoSign/StartCom-issued
certificates, reduce the domain whitelist from the top 1M
to the top 500K. This reduces the overall binary impact from
113K to 65K.

BUG= 685826 

Review-Url: https://codereview.chromium.org/2718243003
Cr-Commit-Position: refs/heads/master@{#453445}

[modify] https://crrev.com/6fc397860ccafa55086456a4d1e6d713c418b41f/net/data/ssl/wosign/wosign_domains.gperf

It would be really nice if Google's release notes for Chrome bothered to mention this (in either v56 or v57 (looks like v57 broke it for us)). It took a while to figure out why our internal sites had suddenly become untrusted - not least because everything in the security dev tab and certificate info was flagged as valid - only the url bar was saying invalid. 

I appreciate that this is chromium project and not directly linked with google chrome release notes but it seems the appropriate place to mention this. 
It did

https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html

Beginning with Chrome 56, certificates issued by WoSign and StartCom after October 21, 2016 00:00:00 UTC will not be trusted. Certificates issued before this date may continue to be trusted, for a time, if they comply with the Certificate Transparency in Chrome policy or are issued to a limited set of domains known to be customers of WoSign and StartCom.
Due to a number of technical limitations and concerns, Google Chrome is unable to trust all pre-existing certificates while ensuring our users are sufficiently protected from further misissuance. As a result of these changes, customers of WoSign and StartCom may find their certificates no longer work in Chrome 56.
In subsequent Chrome releases, these exceptions will be reduced and ultimately removed, culminating in the full distrust of these CAs.
No it didn't rsleevi.

We said in the Chrome ** release notes **.
Apologies for misreading your request. We traditionally only highlight security issues from external parties on those release notes. We also highlight API deprecations and removals for each release separately (such as https://developers.google.com/web/updates/2017/02/chrome-57-deprecations ), but this doesn't fit within the API.

We'll make sure that future changes are better communicated in the release notes. For this particular issue, the aforementioned Blog Post on Google's Security Blog should hopefully have enough information.
Anyway rsleevi, can you provide more details for current Chrome 57?
Is Chrome 57 at the "exceptions reduced" or "ultimately removed full distrust" stage?
And will there be a release notification when a Chrome version is "full distrust"?
Chrome 56 is date, Chrome 57 is limited to the global top million domains that had such certificates, Chrome 58 is limited to the global top 500,000 domains that had such certificates.

We should be able to include release notifications in Chrome 58 and later for each reduction in scope of trust.
Thanks for that change, it was about time. But why not dropping it entirely? Alexa top 1m has probably better it departments with time to fix their ssl than smaller pages do?

Furthermore, It would be really nice if Google would tell people loudly about such changes, in a manner more concrete than "In subsequent Chrome releases, these exceptions will be reduced and ultimately removed", maybe with a concrete timeline ...
Comment 17 Deleted
For those who have the same problem: If you have used HTST and an other/older certificate on your site and replaced it with a StartCom certficate, you get with chrome an NET::ERR_CERT_AUTHORITY_INVALID error WITHOUT the option 'Proceed anyway'.

To solve this you have to go to 'chrome://net-internals/#hsts' and delete the HTST settings for this domain. Then you get back the 'Proceed anyway' opition and can connect to the site.
@rsleevi, I'd like to ask why those CA's homepages still show as valid secure when issuing their own homepage certs?  Does distrust those CAs mean distrust all their issued certs, or only those issued by certain bad root authorizing certs?

Specifically, their homepage cert issuers are:

https://www.startssl.com
CN = StartCom Class 4 EV Server CA
OU = StartCom Certification Authority
O = StartCom Ltd.
C = IL

https://www.wosign.com
CN = WoSign Class 4 EV Server CA G2
O = WoSign CA Limited
C = CN

The distrust is based on domain ranking, phased over releases.
@rsleevi, so since (at least for now) StartCom issues startssl.com's cert, and WoSign issues wosign.com's cert, eventually over some phases these websites will be dis-trusted?
sarjoor - correct. Please see the 2nd to last paragraph of https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html
@awhalley, thanks so much for the clear confirmation!

The question remains ...

Since its actions affect many, Google, as author of Chrome, has a special role and therefore responsibility here. A single commit can break a lot of stuff on the Internet if not communicated loud & clear enough.
(The same is true for other large browser vendors, of course.)

"In subsequent Chrome releases, these exceptions will be reduced and ultimately removed."

* Why is this happening in an in-transparent manner?
* Why is there an exception for popular sites, while smaller sites get punished?
* How can we deal with situations like this in the future.

(+ What is the place to discuss manners like this. Probably not in a bugtracker issue, I guess.)

Thanks. :)
This has been a part of the 58 and 59 release notes. An oversight caused it to be omitted from 57.

- Can you clarify what you believe is not transparent?
- The approach was done to reduce the user and site operator impact. Larger trafficed sites take much longer to migrate and deploy certificates, and failing to do so in a timely fashion causes greater disruption to users. As our goal is to ensure that site operators have sufficient time, and user impact is minimized, an approach based on popularity, which recognized the existing and incipient challenges in the ecosystem, were appropriate.
- We are currently dealing with another CA regarding this, in the discussion at https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ

All of our announcements in the past have involved, at a minimum, discussion on the Google Security blog (https://security.googleblog.com), as well as across a variety of outreach channels (enterprise outreach, developer outreach, press outreach). Our goal is to minimize impact as much as reasonable, but in situations like this, impact may be unavoidable and necessary.
I couldn't find any (not even tentative) schedule for the last steps of the distrust process.

56 - notBefore < 2016-10-21
57 - Alexa 1M whitelist (~17k sites whitelisted)
58 - Alexa 500K (~10k)
59+ - ???

So whats the continuation? 59/250K -> 60/100K -> 61/50K -> 62/25K -> 63/10K -> 64/0?

(I'm planning to contact a few (mostly OSS-related) sites from the whitelist that are still using StartCom to transition away and would prefer to have more accurate data to point to instead of "it will stop working soon(tm)".)
The only details of the plan we have to share is "It will stop working soon(tm)". Please migrate off as soon as possible.

Unambiguously, all WoSign and StartCom certificates will cease working in a future release.

We continue to actively monitor the data both of sites serving these certificates and of user impact, and our goal is to move to full distrust sooner, than later.
Hi rsleevi,
Are there Chrome 58 release notifications about the reduction in scope of trust?
@Ryan stated "This has been a part of the 58 and 59 release notes. An oversight caused it to be omitted from 57." But https://chromereleases.googleblog.com/2017/04/stable-channel-update-for-desktop.html has nothing about StartCom/Wosign
Even the dev console shows nothing for sites that are working for now. This is rather bad for awareness of such website owners, especially considering the majority of WoSign cert owners are Chinese and won't be able to find this bug tracker. 
Posting publicly about this issue and hoping that webmasters see it is not effective.  I only found out about this issue when I got a new certificate from StartSSL in February and found that it didn't work.  None of the browsers I tested told me what the actual problem with the certificate was.  I had to ask online to make any sense of it.

Google should notify sites with these certificates via Google Search Console.

Of the browsers, Chrome has the best error message, but it could drastically improved.   `NET::ERR_CERT_AUTHORITY_INVALID` should be more human readable.  It should also link to an announcement about the issue.
Is there any way to work around this Chrome distrustment? I'm not going to replace all my working certificates valid for 2+ years from now just because Chrome doesn't like them anymore. Is really the only solution to use Firefox or IE?
After April 2017, Mozilla no longer makes any committment that they will remain trusted.
Sign in to add a comment