Given that mozilla seems to have decided to remove WoSign and StartSSL trust bits from NSS but continue to ship the certificates and rely on the notBeforeDate of certificates, what thoughts have been made regarding necessary package changes in Gentoo? Mozilla Root Store Elsewhere (Was Re: StartCom & Qihoo Incidents): https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg04628.html: > I wasn't in this instance, simply noting the following problem: By > assuming all relying parties run code that implements Mozilla's other > revocation methods (OneCRL, custom notBefore checks etc.), the root > list published by Mozilla becomes less useful for relying parties whose > applications do not. and more details all over https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/ and https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/
commit 75289055e52812cff4a897ebf543f09e2e48829b Author: Lars Wendler <polynomial-c@gentoo.org> Date: Tue Oct 25 16:52:15 2016 app-misc/ca-certificates: Revbump to remove untrusted certs (bug #598072) Package-Manager: portage-2.3.2 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> The untrusted certs no longer get installed with =app-misc/ca-certificates-20160104.3.27.1-r1
Thanks. Since this is hardening and not a vuln, closing.
# wget www.gnome.org ERROR: cannot verify www.gnome.org's certificate, issued by ‘CN=StartCom Class 2 Primary Intermediate Server CA,OU=Secure Digital Certificate Signing,O=StartCom Ltd.,C=IL’: Unable to locally verify the issuer's authority. To connect to www.gnome.org insecurely, use `--no-check-certificate'.
I think, it was a mistake to just drop them completely. Even mozilla itself only dropped only newly issued ones, but not old ones. Why should we drop them completely?
(In reply to Vadim A. Misbakh-Soloviov (mva) from comment #4) > I think, it was a mistake to just drop them completely. > Even mozilla itself only dropped only newly issued ones, but not old ones. > Why should we drop them completely? The cert store isn't only used by Firefox, and third party applications (e.g when used by openssl or gnutls) using the cert store have no idea of knowing the special provisions put in place for the checking in NSS/Firefox.
(In reply to Kristian Fiskerstrand from comment #5) > (In reply to Vadim A. Misbakh-Soloviov (mva) from comment #4) > > I think, it was a mistake to just drop them completely. > > Even mozilla itself only dropped only newly issued ones, but not old ones. > > Why should we drop them completely? > > The cert store isn't only used by Firefox, and third party applications (e.g > when used by openssl or gnutls) using the cert store have no idea of knowing > the special provisions put in place for the checking in NSS/Firefox. What can be done is of course to introduce an "experimental-insecure-certs" USE flag that doesn't remove it
Hi, I just noted this and I think it's a bad idea. Mozilla decided to untrust *new* wosign/startcom certs, but there are millions of certs in use that are still accepted. Just to give you an example: I'm still using startcom on some of my own hosts because I used wildcards in the past and it needs some considerations how to transition that to Let's Encrypt and because I have used HPKP and can't switch until the pin expires. It's unfortunate that right now there is no way to deliver more complex rules within ca-certificates (as in "Trust certs from this CA if they were issued before date X"), but I think we should err on the side of not breaking too much things and keep startcom/wosign for a while.
(In reply to Hanno Boeck from comment #7) > Hi, I just noted this and I think it's a bad idea. > > Mozilla decided to untrust *new* wosign/startcom certs, but there are > millions of certs in use that are still accepted. > > Just to give you an example: I'm still using startcom on some of my own > hosts because I used wildcards in the past and it needs some considerations > how to transition that to Let's Encrypt and because I have used HPKP and > can't switch until the pin expires. > > It's unfortunate that right now there is no way to deliver more complex > rules within ca-certificates (as in "Trust certs from this CA if they were > issued before date X"), but I think we should err on the side of not > breaking too much things and keep startcom/wosign for a while. This would reduce security for all other services than web browsing for a company that retracts its public listing due to "As a publicly-listed Chinese company in the United States, Qihoo 360 has faced the pressures of being a public company. Transparency dogged the company, which also has a security software component, and ultimately the company saw the U.S. public markets as incompatible with how the company wanted to conduct business." (https://www.chinatechnews.com/2016/04/27/23475-qihoo-360s-privatization-approved-by-ndrc) .. and a company that "cheated in all anti-virus tests http://www.computerworld.com/article/2917384/malware-vulnerabilities/antivirus-test-labs-call-out-chinese-security-company-as-cheat.html When Qihoo was caught out, Qihoo turned it into a market campaign, calling AV-C outdated and saying Qihoo's cloud engine is much more advanced and announced it quit (http://tech.sina.com.cn/i/2015-05-02/doc-icczmvup0903459.shtml article in Chinese )" that has continued to be deceptive in its behaviour through the auditing period and refusing to take responsibility for the issues that were put forth, and websites/posts being taken down as result of takedown notices when information was offered on at least two instances.
This broke email for me: % esmtp -v ... Connected to MTA Invalid peer certificate (error 19) Disconnected to MTA 0 (null) This is not acceptable. It took me some time to figure out what is going on.
(In reply to Hanno Boeck from comment #7) > > It's unfortunate that right now there is no way to deliver more complex > rules within ca-certificates (as in "Trust certs from this CA if they were > issued before date X"), but I think we should err on the side of not > breaking too much things and keep startcom/wosign for a while. To provide a specific example, gnupg uses the gnutls cert store for --fetch operation, so a user doing gpg --fetch https://github.com/blah can be MITMed by WoSign (they already assigned such a cert in e.g https://crt.sh/?id=29647048 as discussed in https://wiki.mozilla.org/CA:WoSign_Issues#Issue_N:_Additional_Domain_Errors_.28June_2015.29 )
commit 171217a85eefea54a12de02af2bf684af0ff042e Author: Lars Wendler <polynomial-c@gentoo.org> Date: Fri Oct 28 11:28:33 2016 app-misc/ca-certificates: Make removal of untrusted certs optional. Package-Manager: portage-2.3.2 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> You can now re-install these certs with USE="insecure_certs".
To have the history included, [google has now announced] similar removal of trust bits. Although they maintain a whitelist for certain high-value domains they conclude "As a result of these changes, customers of WoSign and StartCom may find their certificates no longer work in Chrome 56." References [google has now announced] https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html
(In reply to Kristian Fiskerstrand from comment #12) > To have the history included, [google has now announced] similar removal of > trust bits. Although they maintain a whitelist for certain high-value > domains they conclude "As a result of these changes, customers of WoSign and > StartCom may find their certificates no longer work in Chrome 56." > > References > [google has now announced] > 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.« That is a big difference compared to not trusting _all_ certificates regardless of their date.
(In reply to octoploid from comment #13) > (In reply to Kristian Fiskerstrand from comment #12) > > To have the history included, [google has now announced] similar removal of > > trust bits. Although they maintain a whitelist for certain high-value > > domains they conclude "As a result of these changes, customers of WoSign and > > StartCom may find their certificates no longer work in Chrome 56." > > > > References > > [google has now announced] > > 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.« > > That is a big difference compared to not trusting _all_ certificates > regardless of their date. You missed "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."
(In reply to Kristian Fiskerstrand from comment #14) > (In reply to octoploid from comment #13) > > (In reply to Kristian Fiskerstrand from comment #12) > > > To have the history included, [google has now announced] similar removal of > > > trust bits. Although they maintain a whitelist for certain high-value > > > domains they conclude "As a result of these changes, customers of WoSign and > > > StartCom may find their certificates no longer work in Chrome 56." > > > > > > References > > > [google has now announced] > > > 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.« > > > > That is a big difference compared to not trusting _all_ certificates > > regardless of their date. > > You missed "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." Since this was brought up again as well, full removal is the only correct thing to do. In Google's case the post goes on to say: """ 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. We remain committed to ensuring the safety and privacy of Google Chrome users. We appreciate the impact to users visiting sites with affected certificates and to the operators who run these sites, but the nature of these incidents, and the need to protect our users, prevent us from being able to take less disruptive steps. """
(In reply to Kristian Fiskerstrand from comment #15) > (In reply to Kristian Fiskerstrand from comment #14) > > (In reply to octoploid from comment #13) > > > (In reply to Kristian Fiskerstrand from comment #12) > > > > To have the history included, [google has now announced] similar removal of > > > > trust bits. Although they maintain a whitelist for certain high-value > > > > domains they conclude "As a result of these changes, customers of WoSign and > > > > StartCom may find their certificates no longer work in Chrome 56." > > > > > > > > References > > > > [google has now announced] > > > > 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.« > > > > > > That is a big difference compared to not trusting _all_ certificates > > > regardless of their date. > > > > You missed "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." > > Since this was brought up again as well, full removal is the only correct > thing to do. Well, full removal means breaking the system of "innocent" users. For example my email provider got their key signed years ago. What additional security would I get by the removal? None, because I use encrypted smtp only to fend off possible snoopers.
(In reply to octoploid from comment #16) > > > > Since this was brought up again as well, full removal is the only correct > > thing to do. > > Well, full removal means breaking the system of "innocent" users. > For example my email provider got their key signed years ago. > What additional security would I get by the removal? None, because > I use encrypted smtp only to fend off possible snoopers. Ensuring some element of confidence in the X.509 Global PKIX system is responsibility of every downstream vendor. Are you saying that the cost of changing the certificate in your case is higher than the reward to security for every other consumer of the trust store, e.g gnupg keyserver access, or security while using jabber/XMPP? A CA that demonstrates lack of care for security needs to be removed.
(In reply to Kristian Fiskerstrand from comment #17) > (In reply to octoploid from comment #16) > > > > > > > Since this was brought up again as well, full removal is the only correct > > > thing to do. > > > > Well, full removal means breaking the system of "innocent" users. > > For example my email provider got their key signed years ago. > > What additional security would I get by the removal? None, because > > I use encrypted smtp only to fend off possible snoopers. > > Ensuring some element of confidence in the X.509 Global PKIX system is > responsibility of every downstream vendor. Are you saying that the cost of > changing the certificate in your case is higher than the reward to security > for every other consumer of the trust store, e.g gnupg keyserver access, or > security while using jabber/XMPP? A CA that demonstrates lack of care for > security needs to be removed. No, but at least the removal should not be rushed. It takes time until every StartCom customer could change their certificates. So give them a few weeks/months. This should be enough and doesn't cause any breakage in the meantime.
(In reply to octoploid from comment #18) > (In reply to Kristian Fiskerstrand from comment #17) > > (In reply to octoploid from comment #16) > > > > > > > > > > Since this was brought up again as well, full removal is the only correct > > > > thing to do. > > > > > > Well, full removal means breaking the system of "innocent" users. > > > For example my email provider got their key signed years ago. > > > What additional security would I get by the removal? None, because > > > I use encrypted smtp only to fend off possible snoopers. > > > > Ensuring some element of confidence in the X.509 Global PKIX system is > > responsibility of every downstream vendor. Are you saying that the cost of > > changing the certificate in your case is higher than the reward to security > > for every other consumer of the trust store, e.g gnupg keyserver access, or > > security while using jabber/XMPP? A CA that demonstrates lack of care for > > security needs to be removed. > > No, but at least the removal should not be rushed. The discussions have been ongoing for more than two months already, nothing about it is rushed. > It takes time > until every StartCom customer could change their certificates. And even longer if they don't feel the need to do so. Changing a certificate takes, at maximum, 5-10 minutes for every site, and even if not wanting to use Lets Encrypt in the end, a temporary one for 3 months can be requested from e.g https://gethttpsforfree.com without any special acme setup. > So give them a few weeks/months. This should be enough and doesn't > cause any breakage in the meantime. That _is_ broken in the mean time, as the security of the trust store is known to be compromised.
I am not happy with the name of the USE flag. "insecure_certs" isn't true from my view. The certs issued by WoSign and StartCom aren't _insecure_. The two companies violated private BrowserCAB rules but they did not issue fraudulent or unauthorized certificates like Symantec did in the past. Because browsers are still trusting these CAs for existing certificate consumers won't replace certificates ASAP. This will result in a problem for Gentoo-user only because they will be the first (and probably only users) who will notice. Now we decided to do something and don't wait for upstream (i.e. Debian) like we have done in the past. Why? But I am fine with providing an option. However I don't like the name. Like shown theses certificates aren't insecure. I would name the USE flag "strict". I wouldn't turn that flag on per default until Jan 2017.
(In reply to Thomas Deutschmann from comment #20) > I am not happy with the name of the USE flag. "insecure_certs" isn't true > from my view. The certs issued by WoSign and StartCom aren't _insecure_. The > two companies violated private BrowserCAB rules but they did not issue > fraudulent or unauthorized certificates like Symantec did in the past. They issued fraudlent notBeforeDate certificates to get around SHA1 restriction, they issued certificates validated on non-system ports, they issued certs for domains for which validation only happened on subdomain(including github), they issued an unauthorized cert for alicdn.com. They continued lying regarding StartCom acquisition and sending off takedown notices to websites mentioning that. > > Because browsers are still trusting these CAs for existing certificate > consumers won't replace certificates ASAP. This depends on browser, but it is part of the problem that e.g mozilla has added requirements for certs to consider valid that can't reasonably be implemented by third party users of the cert store. > This will result in a problem for > Gentoo-user only because they will be the first (and probably only users) > who will notice. Hopefully they file bugs upstream > > Now we decided to do something and don't wait for upstream (i.e. Debian) > like we have done in the past. Why? Because the security-focus is increasing?
Just to be sure: I don't want to defend WoSign/StartCom. My goal is to establish a default behavior how Gentoo react on things like that (in future). (In reply to Kristian Fiskerstrand from comment #21) > (In reply to Thomas Deutschmann from comment #20) > > I am not happy with the name of the USE flag. "insecure_certs" isn't true > > from my view. The certs issued by WoSign and StartCom aren't _insecure_. The > > two companies violated private BrowserCAB rules but they did not issue > > fraudulent or unauthorized certificates like Symantec did in the past. > > They issued fraudlent notBeforeDate certificates to get around SHA1 > restriction, they issued certificates validated on non-system ports Please notice that this is only a validation of the CAB forum's policy. But the system's certificate store is used by more than just browsers... Are you familiar with the WorldPay case? Two major browser vendors broke/ by-passed their own policy and ignored CAB guidelines. This was criticized in the community. > they issued certs for domains for which validation only happened on > subdomain(including github) But WoSign/StartCom isn't the first CA who failed in domain validation. > they issued an unauthorized cert for alicdn.com. That's not true: > This "misissuance" was possible only because alicdn.com was, for some > period of time, controlled by an attacker. Therefore, no blame can be > attributed to WoSign for the misissuance itself. > > Source: https://wiki.mozilla.org/CA:WoSign_Issues#Issue_T:_alicdn.com_Misissuance_.28June_2016.29 > They continued lying regarding StartCom acquisition and sending > off takedown notices to websites mentioning that. I can't tell you if they lied or not. However this was, in the Mozilla case, only a validation of Mozilla's own additional policy. The current CA Browser Forum Baseline Requirements v1.4.1 don't handle changed CA ownership. > > Because browsers are still trusting these CAs for existing certificate > > consumers won't replace certificates ASAP. > > This depends on browser, but it is part of the problem that e.g mozilla has > added requirements for certs to consider valid that can't reasonably be > implemented by third party users of the cert store. > > > This will result in a problem for > > Gentoo-user only because they will be the first (and probably only users) > > who will notice. > > Hopefully they file bugs upstream Bug against what? It will be only Gentoo who won't trust _any_ WoSign/ StartCom certificate anymore. For no reasons because everything else will handle that at application level. > > Now we decided to do something and don't wait for upstream (i.e. Debian) > > like we have done in the past. Why? > > Because the security-focus is increasing? In future, what will we do when another CA does something wrong? Don't forget that you have taken action _before_ the CAB forum voted on that issue. We are only seeing some uncoordinated individual actions of some browser vendors... So will we take action in future when Apple (they were the first who announced to take action) and/or Mozilla do something? Or do we wait for Google? Do we wait for Microsoft? Other distributions currently don't have plans to remove WoSign/StartCom. Most of them will depend on Mozilla's CA bundle and it doesn't look like that Mozilla will remove these CAs (they handle that as well at application level...) so it is only Gentoo... To summarize: - Please consider renaming the USE flag. "Insecure" is wrong. The CAs aren't compromised and there's nothing wrong to accept their certificates at this moment (it is a policy thing, nothing else; Otherwise please explain why we don't take action against Symantec: Instead of a notBeforeDate value we can't check for WoSign/StartCom (and that's the argument to remove WoSign/StartCom today) Google demand that any certificate issued by Symantec after June 1st must conform to the Chromium Certificate Transparency policy or may result in interstitials or other problems when used in Google products due to Symantec's latest public incident). - If bug 504892 would have been resolved this would be the way to go instead of deleting CAs. That way we could distrust any CA we want per default but the user would have the possibility to manage trust on his/ her own.
(In reply to Thomas Deutschmann from comment #22) > > Are you familiar with the WorldPay case? Two major browser vendors broke/ > by-passed their own policy and ignored CAB guidelines. This was criticized > in the community. The difference being they asked for the authoriziation up front instead of backdating certificates > > > they issued an unauthorized cert for alicdn.com. > > That's not true: > > > This "misissuance" was possible only because alicdn.com was, for some > > period of time, controlled by an attacker. Therefore, no blame can be > > attributed to WoSign for the misissuance itself. > > > > Source: https://wiki.mozilla.org/CA:WoSign_Issues#Issue_T:_alicdn.com_Misissuance_.28June_2016.29 > Fair enough > > > They continued lying regarding StartCom acquisition and sending > > off takedown notices to websites mentioning that. > > I can't tell you if they lied or not. > > However this was, in the Mozilla case, only a validation of Mozilla's own > additional policy. The current CA Browser Forum Baseline Requirements > v1.4.1 don't handle changed CA ownership. Chance of control is a natural element of trust consideration > Bug against what? It will be only Gentoo who won't trust _any_ WoSign/ > StartCom certificate anymore. For no reasons because everything else will > handle that at application level. That does not protect users of Gentoo for the applications that doesn't > > > > > Now we decided to do something and don't wait for upstream (i.e. Debian) > > > like we have done in the past. Why? > > > > Because the security-focus is increasing? > > In future, what will we do when another CA does something wrong? Don't > forget that you have taken action _before_ the CAB forum voted on that > issue. CAB only has a mandate to provide recommendations through baseline requirements, they have a restricted mandate by bylaws to avoid anti-competitive measures. > We are only seeing some uncoordinated individual actions of some browser > vendors... > > So will we take action in future when Apple (they were the first who > announced to take action) and/or Mozilla do something? Or do we wait for > Google? Do we wait for Microsoft? > > Other distributions currently don't have plans to remove WoSign/StartCom. citation needed
*** Bug 602836 has been marked as a duplicate of this bug. ***
