WoSign's response[1] might also be of interest in this context.
They seem to take, at least partially, ownership of the issues. Am I also correct in that this only affects intermediate certificates? I see they say that they will have a workaround in place in about a months time.
> Am I also correct in that this only affects intermediate certificates?
No. As the article states, it will affect any certificates that chain up to the specified root certificates (including and intermediate and end-entity certificates).
> I see they say that they will have a workaround in place ...
From previous statements, I believe WoSign's plan is to resell another CA's certificates during the period that they don't have a root of their own in the trust store.
> From previous statements, I believe WoSign's plan is to resell another CA's certificates during the period that they don't have a root of their own in the trust store.
or find/buy another currently trusted CA that cross-signs their new root. I'm sure they can find somebody.
> There will be new SSL certificates issued by a new WoSign intermediate CA which is signed by the one of global trusted root CA, it supports all the browsers (including Firefox). This will be done within one months.
I wonder who's going to be stupid/reckless enough to sign that intermediate.
Indeed, any company that signs any of their intermediates would want to have an ironclad indemnification, penalty clauses and a fully paid up escrow (hosted in a neutral country like Switzerland, Ireland or the like) in any contract.
But I suspect that another Chinese company or Chinese owned company will be selected to be the signor.
It remains to be seen whether they will actually hold the private key for that intermediate certificate and issue end-entity certificates from it, or if this is just some sort of reselling deal where a different, trusted CA holds the key, performs domain validation, etc (which is a fairly common practice).
I have my doubts about whether Mozilla will accept them continuing to operate an actual CA with a new cross-signed certificate prior to them completing the inclusion process. CAs need to disclose these intermediate certificates, and I expect it would end up being revoked, with possible sanctions for whoever cross-signs them.
1. They take no direct responsibility, nor try to explain, or excuse the deception claims. To WoSign, the whole thing is "an incident", not a premeditated deception.
2. They still do not acknowledge their ownership of StartCom, or explain why that was kept in the dark. In fact they keep talking about "4 WoSign roots" despite the 6 roots mentioned by Mozilla.
I am kind of thankful for this. It gave us immediate time budget to switch our certificate process over to Letsencrypt.
I'm also glad it does not affect existing certs, since we need some weeks to ramp up the LE certs because of the 20 new certs per week limit (we can continue to only bundle subdomains per cert that are actually used on the same host/loadbalancer).
Many if not all of the acme clients out there store the key and certificate as a file. Just copy that to the various machines terminating the SSL connection.
In our case, there's a script on the frontend machine running HAProxy that's fetching the certificates and putting them on a shared file system so the backup machine also has access to them.
The traffic between frontend host and application servers is unencrypted in our case as it's all one rack under our control. If it wasn't, we'd be using a self-signed certificate for that connection.
Interestingly, over at the Google Certificate Transparency group, it looks like both StartCom's and WoSign's CT log servers were recently included into Chrome.
Indeed. For those curious, CT is designed to "discover" SCTs that were not publicly shown by the log, so that the log can operate without a lot of trust, though this did not happen here (someone just found them operating two logs...)
I guess I'm not the best person to criticize other logs, though. :-)
"Please note that while both Symantec and CNNIC's logs are presently enabled in the current Chrome stable release (Chrome 52), both WoSign and StartCom's logs will not be recognized until Chrome 54, which is presently the Dev channel release."
I don't like this at all. The only value left in WoSign root certificates is in issuing backdated certificates that wouldn't be widely distributed. So basically the only way to extract any money out of their current root keys is to sell rogue certificates for targeted attacks.
Mozilla has explicitly stated that if they find any evidence of this happening, both WoSign and StartCom will be completely revoked - both for old and new certificates.
> If additional back-dating is discovered (by any means) to circumvent this control, then Mozilla will immediately and permanently revoke trust in the affected roots.
The point of doing it this way is that it puts the CA out of business but doesn't break the Web, which makes it the only really practical way for browsers to exert leverage over too big to fail CA's.
more accurately, this way all the existing issued certificates are not invalidated. the idea is not to punish the customers of wosign, startcom who already paid for a certificate and have it in use.
if they removed it entirely, those would all break which would be inconvenient to the otherwise innocent customers.
Yes, of course what you are saying is true, but I feel that this is underestimating the risk of keeping them in the system.
Wosign/startcom are known bad actors and put the entire ecosystem at risk because browsers trust all CA's equally.
Certificates are ultimately fungible with redundant CA's globally. One certificate is essentially as good as another, from the browser perspective (and nearly all site visitors).
This interchangeability:
Reduces the risk for 'otherwise innocent customers' in terms of cost (especially now with letsencrypt) so it's "easy" (or at least possible) for customers to replace their existing certificates when they had put trust in an untrustworthy vendor, and
Increases the risk that Wosign/startcom will sign bad certificates by backdating them (especially because signing certs is, in fact, their business model and now they have no incentive to not sign bad certs by backdating, since their business is basically dead now anyway.)
The risk is too high to NOT revoke all of their certificates, unless the current certs were able to all be enumerated and pinned. Letsencrypt only issues certificates for 3 months in order to provide some semblance of control.
If they wanted to have their cake and eat it too, Mozilla could give a thirty or 60 day warning period saying 'upgrade your certs NOW' or change them to 'untrusted' (grey) for that period of time and then completely remove (red) the way Chrome has done in the past with legitimate but no-longer-secure certs.
They have a pretty strong incentive to not backdate certs after all the attention this has gotten.
Distrusting future certs punishes the company, distrusting all of them punishes all past customers and their users, and encourages people to just switch browsers.
That's what's meant by "breaking the Web": releasing a browser that, from a user's perspective, just doesn't work in some fundamental way.
In addition to the inconvenience to site owners and users, it would also lead people to blame the browser if the sites still work in other browsers, which would make it hard for any one browser to unilaterally distrust a CA.
These guys must be joking. Trust has been lost, the roots should be permanently revoked.
If anything, I think Mozilla's actions are not severe enough. How likely is it that Mozilla doesn't know the full story? There may be additional violations that have been missed.
Mozilla has revoked the CA certificate moving forward. Already-issued certificates are unaffected, to allow current customers time to migrate to a more reputable CA. If they were to immediately revoke the current roots, then thousands of sites would suddenly report certificate errors--which would train users to click through them, helping nobody.
The axe Mozilla is holding over WoSign is the threat of immediate full revocation if WoSign is caught doing backdating again. Given that WoSign has been coerced into cooperating with publishing all CSRs via Certificate Transparency, and that there is likely to be a much larger group of people watching carefully for violations, I don't expect it to take very long for future backdated certificates to be caught if WoSign does try it.
Maybe I'm reading this wrong, but doesn't this mean that the actual, found-in-the-wild backdated certs will still be trusted?
At any rate, this gets to the crux of PKI's problem. This was a backdating of certificates because of a change in policy about the cryptographic strength of hashes. But the weak point in PKI isn't the cryptography, it's the agents.
IIRC they were revoked in the course of the investigation (somewhere in the last two months).
That being said, the risky bit is that they actually signed those SHA-1 certificates in the first place - a certificate that could be specially crafted to "collide" with one for a site an attacker wants to impersonate. It's not really all that important whether they're revoked (though there's nothing wrong with revoking them just in case).
As for CAs being the weak point, luckily we're going to be living in a mandatory Certificate Transparency world in the not-so-far future.
IDK, I'm worried this is an example of what that will look like: since the CAs are the actual stakeholders, the default question is going to be "what can we do to make this CA trustworthy again?" rather than "how can we make sure this CA never has another cert trusted again?"
The backdated certificates that have already been found are explicitly being added to OneCRL, which is to say that they are explicitly distrusted independent of what the CRL/OSCP responder of WoSign and StartCom say.
It'd be nice if we could distrust the whole CA system and start from scratch. (of course, to everyone who is saying to themselves that this is absurd and unrealistic.. yes, of course you're right.. for the moment.)
It seems pretty clear that the future lies in the blockchain.
Haven't you heard, you can solve any problem by throwing a blockchain at it! ;-)
On a more serious note, Certificate Transparency, which will become mandatory in Chrome in about a year, uses technology that is strongly related to blockchains, so we're really not too far from a blockchain-like solution for the Web PKI.
I agree that CT uses a technology related to blockchains, but as I noted above, Ben Laurie has been pretty vocal in saying that the Bitcoin-style PoW blockchain isn't a technology that he favors, and I think he thinks CT is importantly different in some respects (for example in accepting more centralization in the operation of logs: an uninvolved anonymous party can't show up and "mine" a CT log event).
Not the OP, but I imagine he has something like namecoin in mind. Domains are tied to cryptographic keys which are also used for encryption+authentication, and the blockchain stores the mapping of names to keys.
It's not ready for primetime, and it has its own issues. I don't really see it gaining much traction. But it does present an alternative approach to the problem.
How do you tie a domain to a key in this model? That's the specific thing that CAs do. The Wikipedia article seems to hand wave over this and I don't see an obvious answer on the namecoin site (though I assume it's there if I dig enough).
I don't know if there are established formats to do it, but you would publish the public key in the namecoin record of your domain. You can only do that if you currently own the name in the namecoin chain, similar to how DANE would put a key into DNS.
You register a domain by spending namecoin in a reg tx, which becomes immutable in the bc. Problem is that when a court says Cocacola.blockchain_namespace is the legal property of the Coke, and the owner is some kid in China who won't hand over the keys, no Corp would use it for DNS.
Names should be strong to prevent spoofing but not so strong that squatters and unlawful holders of keys can disrupt their legitimacy.
So basically it doesn't at all solve the problem. Immutable domain names are not a good thing in general (though certainly in specific cases it could be), especially when as you noted squatting is inevitable.
He seems to have argued that CT's log works on different principles, although surely it's influenced by all of the revitalized consensus work that's happened after the Bitcoin paper.
> No longer accept audits carried out by Ernst & Young Hong Kong
This is...a big deal? If Mozilla believes E&Y HK was negligent or complicit in WoSign's lies, then that newfound scepticism should extend to the office's financial audits.
Seems weird to tie it just to the Hong Kong office though. These guys are trading on the Ernst & Young name to get the positive reputation associated with it, why should the negative publicity not flow the other way?
They still have the name, so one can only surmise that Ernst & Young stands behind their actions.
Aren't most audits a joke anyhow? I know companies 'have' to do them but I've never been a part of a good or accurate one (not just E&Y either). Most auditors are just looking to CYA and get the paper signed.
Can someone explain what the business reason for backdating certs is? I understand it was to get around the notAfter but I don't understand who gains from this? Is it just old code they are too cheap/lazy to update?
To create SHA-1 certificates for compatibility with older software. SHA-1 certificates may not be issued after December 31, 2015 and in any case browsers will not trust them. They created new certificates in 2016, with a "Start Date" in 2015 so that they satisfied this rule. This is forbidden for two reasons, first you cannot "back date" certificates and second you are no longer allowed to issue SHA-1 certificates, so they back dated to work around this.
51 comments
[ 3.2 ms ] story [ 97.3 ms ] threadThey seem to take, at least partially, ownership of the issues. Am I also correct in that this only affects intermediate certificates? I see they say that they will have a workaround in place in about a months time.
[1]: https://www.wosign.com/English/News/announcement_about_Mozil...
No. As the article states, it will affect any certificates that chain up to the specified root certificates (including and intermediate and end-entity certificates).
> I see they say that they will have a workaround in place ...
From previous statements, I believe WoSign's plan is to resell another CA's certificates during the period that they don't have a root of their own in the trust store.
or find/buy another currently trusted CA that cross-signs their new root. I'm sure they can find somebody.
edit: yes. that's what they are going to do according to https://www.wosign.com/English/News/announcement_about_Mozil...:
> There will be new SSL certificates issued by a new WoSign intermediate CA which is signed by the one of global trusted root CA, it supports all the browsers (including Firefox). This will be done within one months.
I wonder who's going to be stupid/reckless enough to sign that intermediate.
But I suspect that another Chinese company or Chinese owned company will be selected to be the signor.
I have my doubts about whether Mozilla will accept them continuing to operate an actual CA with a new cross-signed certificate prior to them completing the inclusion process. CAs need to disclose these intermediate certificates, and I expect it would end up being revoked, with possible sanctions for whoever cross-signs them.
You have a much higher opinion of the probity (and competence) of CAs than is probably warranted.
1. They take no direct responsibility, nor try to explain, or excuse the deception claims. To WoSign, the whole thing is "an incident", not a premeditated deception.
2. They still do not acknowledge their ownership of StartCom, or explain why that was kept in the dark. In fact they keep talking about "4 WoSign roots" despite the 6 roots mentioned by Mozilla.
I'm also glad it does not affect existing certs, since we need some weeks to ramp up the LE certs because of the 20 new certs per week limit (we can continue to only bundle subdomains per cert that are actually used on the same host/loadbalancer).
I'm wondering if there's been any progress in finding an easy solution for this use-case.
In our case, there's a script on the frontend machine running HAProxy that's fetching the certificates and putting them on a shared file system so the backup machine also has access to them.
The traffic between frontend host and application servers is unencrypted in our case as it's all one rack under our control. If it wasn't, we'd be using a self-signed certificate for that connection.
https://groups.google.com/a/chromium.org/forum/#!topic/ct-po...
I guess I'm not the best person to criticize other logs, though. :-)
Chrome 54 is now in stable.
> If additional back-dating is discovered (by any means) to circumvent this control, then Mozilla will immediately and permanently revoke trust in the affected roots.
There's already evidence of this happening. It happened. Why does it have to happen again. Just revoke em.
if they removed it entirely, those would all break which would be inconvenient to the otherwise innocent customers.
Wosign/startcom are known bad actors and put the entire ecosystem at risk because browsers trust all CA's equally.
Certificates are ultimately fungible with redundant CA's globally. One certificate is essentially as good as another, from the browser perspective (and nearly all site visitors).
This interchangeability:
Reduces the risk for 'otherwise innocent customers' in terms of cost (especially now with letsencrypt) so it's "easy" (or at least possible) for customers to replace their existing certificates when they had put trust in an untrustworthy vendor, and
Increases the risk that Wosign/startcom will sign bad certificates by backdating them (especially because signing certs is, in fact, their business model and now they have no incentive to not sign bad certs by backdating, since their business is basically dead now anyway.)
The risk is too high to NOT revoke all of their certificates, unless the current certs were able to all be enumerated and pinned. Letsencrypt only issues certificates for 3 months in order to provide some semblance of control.
If they wanted to have their cake and eat it too, Mozilla could give a thirty or 60 day warning period saying 'upgrade your certs NOW' or change them to 'untrusted' (grey) for that period of time and then completely remove (red) the way Chrome has done in the past with legitimate but no-longer-secure certs.
Distrusting future certs punishes the company, distrusting all of them punishes all past customers and their users, and encourages people to just switch browsers.
In addition to the inconvenience to site owners and users, it would also lead people to blame the browser if the sites still work in other browsers, which would make it hard for any one browser to unilaterally distrust a CA.
These guys must be joking. Trust has been lost, the roots should be permanently revoked.
If anything, I think Mozilla's actions are not severe enough. How likely is it that Mozilla doesn't know the full story? There may be additional violations that have been missed.
The axe Mozilla is holding over WoSign is the threat of immediate full revocation if WoSign is caught doing backdating again. Given that WoSign has been coerced into cooperating with publishing all CSRs via Certificate Transparency, and that there is likely to be a much larger group of people watching carefully for violations, I don't expect it to take very long for future backdated certificates to be caught if WoSign does try it.
At any rate, this gets to the crux of PKI's problem. This was a backdating of certificates because of a change in policy about the cryptographic strength of hashes. But the weak point in PKI isn't the cryptography, it's the agents.
That being said, the risky bit is that they actually signed those SHA-1 certificates in the first place - a certificate that could be specially crafted to "collide" with one for a site an attacker wants to impersonate. It's not really all that important whether they're revoked (though there's nothing wrong with revoking them just in case).
As for CAs being the weak point, luckily we're going to be living in a mandatory Certificate Transparency world in the not-so-far future.
It seems pretty clear that the future lies in the blockchain.
On a more serious note, Certificate Transparency, which will become mandatory in Chrome in about a year, uses technology that is strongly related to blockchains, so we're really not too far from a blockchain-like solution for the Web PKI.
http://www.links.org/files/decentralised-currencies.pdf
It's not ready for primetime, and it has its own issues. I don't really see it gaining much traction. But it does present an alternative approach to the problem.
Names should be strong to prevent spoofing but not so strong that squatters and unlawful holders of keys can disrupt their legitimacy.
https://news.ycombinator.com/item?id=12784295
(Certificate Transparency is basically a Blockchain. And this may be one of the few cases where a blockchain-like technology actually makes sense.)
http://www.links.org/files/decentralised-currencies.pdf
He seems to have argued that CT's log works on different principles, although surely it's influenced by all of the revitalized consensus work that's happened after the Bitcoin paper.
This is...a big deal? If Mozilla believes E&Y HK was negligent or complicit in WoSign's lies, then that newfound scepticism should extend to the office's financial audits.
They still have the name, so one can only surmise that Ernst & Young stands behind their actions.