CA:WoSign Issues
wiki.mozilla.org
wiki.mozilla.org
I started wondering this after they declined to remove StartSSL after the Heartbleed fiasco, and while I sort of understood the reasoning there in isolation, between that incident and this long list of WoSign violations, I'm really getting the sense that CA's are "too big to fail" and that the downsides of suddenly breaking huge parts of the internet on unsuspecting users mean that the threat of removing badly-behaving CA's is an empty one. What would a CA have to do to actually be removed, especially if they were to sign really huge sites?
This is one of those ideas that sounds like common sense when you hear or think about it the first time, but falls apart on scrutiny. Ryan Sleevi has done a much better job picking it apart than I can here, but among the numerous problems with it:
* The most important TLDs are transnational, and their trust hierarchies back into corporations (corporations, I will cheerfully and without irony point out, who are subject to the whims of the FVEY IC).
* It's jingoistic, suggesting we should base trust decisions not on technology or even, really, on policy, but rather on nationalism.
* It consigns residents of countries with oppressive governments to total control by their governments, while at the same time making usage constraints based on those TLDs (such as local mandates to use services whose names end in .XX for XX in $bad_countries) much more powerful.
* It further promotes the idea that security should somehow be tied to the DNS, despite the fact that the DNS is itself not transparently managed, and is often managed at odds with the interests of Internet users as a whole.
* By factionalizing Internet trust, it harms interoperability and also makes it harder to introduce further constraints into the certificate system by essentially declaring up front that we're conceding Internet trust policy to individual nations. * It greatly complicates the security stories of companies that have adopted vanity domain names in random countries, which, whatever you think of those companies (koff! Pinboard), is an unforced error.
Of all the things we can spend time on to improve Internet security, this is not one of the better ones.
Are they? I always thought that .com, .edu, .net et al. are American. I suppose one could argue that .eu is transnational, although the EU are trying very hard to invent their own postmodern nation.
> It's jingoistic, suggesting we should base trust decisions not on technology or even, really, on policy, but rather on nationalism.
It's not really jingoism, although it might be nationalism. And is it even nationalism, when each nation-state makes its corporate decisions in a manner which is acceptable to the members of said state?
> It consigns residents of countries with oppressive governments to total control by their governments
… which they already are under, so it doesn't make anything worse. And they are, of course, free to revolt, as oppressed peoples have done throughout history, sometimes succeeding and sometimes failing.
> By factionalizing Internet trust
You say factionalising, I say federating. It doesn't make any sense to me for a corporation in Canada to certify the identity of a site in Iran for a resident of Guinea-Bissau, which is the current situation. Federation seems to me to be the only solution capable of scaling to a world of billions.
> It greatly complicates the security stories of companies that have adopted vanity domain names in random countries
I think the unforced error was placing their identities in the hands of foreign states.
And, of course, with domain-level validation, their security is already in the hands of those states.
When ANSSI did it, they got name-constrained to French TLDs only: https://bugzilla.mozilla.org/show_bug.cgi?id=952572
When CNNIC did it, they were distrusted: https://blog.mozilla.org/security/2015/04/02/distrusting-new...
Security isn't some taxation game where you find a loophole for your weekend car in the rules, it's about outcomes.
Enterprises wanted these certificates because the alternative to them is installing additional root certificates on everyone's desktop machines, which is a logistical pain.
I'm not excusing that CA transaction. Issuing CA=YES certificates as a convenience for enterprise security teams is terribly irresponsible, and never should have been allowed.
But, at the the the Trustwave thing happened, it was not expressly black-letter against the rules, and so Trustwave didn't get the CA death penalty for it.
They would, supposedly, if they did it again.
I certainly think that in the circumstances, no, they did not. The Mozilla CA policy isn't some legally binding document. They are free to change it and still death-penalty whoever was ultimately responsible for these rogue certificates.
In this case, the book said "I guess proxy MITM CA=YES certificates are fine, as long as you're careful".
Policy was just the excuse. We saw what happened with CNNIC. Coordinated press releases.
You keep writing as if it's common sense that the policy should say "nobody can issue CA=YES certificates to enterprises". But while I agree strongly that they shouldn't, this is not common sense. The certificates that Trustwave sold were never deployed on the public Internet, and their disclosure outside of whatever giant bank bought them would presumably have been accompanied by massive civil liability.
The policy didn't mention this behavior not because it never occurred to anyone to ban it, but because it was overtly, actively thought to be OK, by pretty much every stakeholder, until browsers started getting better at monitoring certificate issuance.
Really, the simple truth is: you have Google to thank for pretty much every positive shift in norms about SSL/TLS CAs. Until they built the team they have doing this today (which is amazing), certificate issuance was --- not hyperbolically, but actually, factually --- the lawless wild west.†
Do I wish they'd built that team a few years earlier? Yes, of course. I also wish heap and integer overflows were better known in the early 90s. You can't always get what you want.
† The Google team will pointedly add that we should be thanking the Mozilla team for the work they've been doing on keeping a coherent CA policy and trusted root set going all these years; as you can see from this thread, it's a thankless task. I don't agree with all of Mozilla's decisions, but if you throw down in a m.d.s.policy thread about them being incompetent or ineffectual, be prepared to have people who have forgotten more about certificate issuance than you've ever learned give you some pretty vivid comparisons to how other certificate stores have been managed all this time.
It was a different time then, and we've gotten better at expecting CAs to be competent. The probability that action will be taken today for the same thing is 1.
"WONTFIX" is the technical status of the Bugzilla bug, because there wasn't a code change, but it's clear that Mozilla took a policy action:
> I have posted a draft CA Communication in the mozilla.dev.security.policy forum for review/discussion. My intent is to make it clear that this type of behavior will not be tolerated for subCAs chaining to roots in NSS, give all CAs fair warning and a grace period, and state the consequences if such behavior is found after that grace period. There is also an action item for CAs to update their CP/CPS to make it clear that they will not issue subCAs for this purpose.
(That also happened when the browser world was less good at dealing with bad CAs, in general)
No, that can not stand.
As far as CA policy goes, 2012 was the very distant past. You might as well accuse Mozilla of poor judgment for allowing MD5 certificates in 2012, it would make as much sense.
Honestly, I'm not sure how you plan to argue your way around a situation where I ended up with a rogue "mail.google.com" certificate accepted by my browser. That wasn't in the rules?! The CA wasn't clear on the policy for that?
https://news.ycombinator.com/item?id=12445837
... nobody had clearly explained to you what the specific transaction Trustwave got in trouble for was actually about.
Now you know, so "this will not stand" and "Trustwave stuck its hand in the garbage disposal" shouldn't be germane anymore. Once again: the whole point of those certificates is to sign domains the certificate owner doesn't control. They're sold only to giant corporations with huge amounts of insurance, and they're contractually obligated to ensure they're deployed only on the corporation's own network.
They're also not allowed anymore.
1. Ask for a list of all issued certificates, get signed certificate timestamps (SCTs) for all of them, and require that all certs issued by the CA have working CT. This essentially prevents all further misissuance (or, at least, makes it very public).
2. If the CA is so bad at life that it doesn't know what certificates have been issued, require CT for all new certificates (trusting the self-stated signature date on the certificate), and have a sword hanging over their head if any evidence arises that the CA has backdated any certificates.
Chrome did #2 for Symantec, and then (I believe) moved to #1, and Symantec is definitely a too-big-to-fail CA.
https://security.googleblog.com/2015/10/sustaining-digital-c...
https://knowledge.symantec.com/support/ssl-certificates-supp...
https://groups.google.com/a/chromium.org/d/msg/ct-policy/hNK...
Of course, Mozilla needs to add support for CT for this approach to work.
Doesn't that just bring us right back to "too-big-to-fail CA"?
We have some certificates that we have to start the renewal process 2-3 months out, because we have a lot of alternate names of domains we don't (directly) control (white-labelled service).
Thankfully we don't use WoSign for any of our certificates, but if it were say Symantec or someone else that got into trouble? Thirty days isn't enough time.
A thirty day notice that nothing issued after the date, and a 6 month migration period would be more like a graceful exit period. Still a stressful period, but less utter panic inducing.
If you issue them from the same CSR / key, you can even configure your web server to send both certs in the certificate chain, and most clients will figure out which one they trust without requiring manual intervention by the site operator.
If CAs were being killed every few months then that would be a reasonable thing to do - but not for such a rare occurrence.
If you give CAs a pile of requirements and say "Do not do these incorrectly" (which is what browsers do to all CAs), they can always argue that they made an honest mistake and they fixed it. Maybe they shouldn't have that room for argument, but they do. But if you say "Do not backdate certs," you've given them one thing to get right, that is hard to get wrong by mistake. At that point, a backdated cert implies either malice or losing control of the raw private key material, both of which clearly demand revocation.
If you need a new certificate in a terrible rush, you can backdate.
Now, that's not what happened here. I would chalk this up to a cultural shift between the Americans and Europeans making the rules at the CA/B forum and the WoSign folks who honestly never imagined they would be expected to comply with rules that couldn't be checked---that a rule would say "don't sign sha-1 after Jan 1" as opposed to "don't sign sha-1 with a NotBefore after Jan 1."
(Of course the complexity now re-introduces some room for "honest" mistakes.)
Is there any chance of this happening?
That said, when you read the email thread, it's abundantly clear that WoSign is not saying what they should be saying. The first response document is inadequate (although they're working on a second document in response to the extra incidents): it seems like WoSign is trying to say "we quickly fixed every instance brought up to us!" and they aren't understanding that said answer isn't good enough for such a serious breach of trust. The remedy at this point is likely to be at least as severe as forbidding any certificate with an issuedBefore of soon. Honestly, if you're a sysadmin using a WoSign cert, I would recommend immediately looking into obtaining a cert from another CA as a backup.
EDIT: Now that I think about it, it must be possible, Certificate Patrol is looking at the cert info, I'll see how they do it.
[0] https://addons.mozilla.org/en-US/firefox/addon/red-jacket/ (this is necessary since there's no built-in UI in Firefox to distrust intermediate certificates: https://bugzilla.mozilla.org/show_bug.cgi?id=585352)
Then if you use like a "C-rated" CA, your HTTPS score is also limited to B. A B-rate CA would limit your HTTPS score to A, and only an A-rated CA would allow you to get A+ on SSLabs. Something along those lines.
I imagine rating the CAs would be quite a complex task, but they could start with the big ones first that own 80-90% of the market.
Also, it sounds like something that will be very easy to corrupt.
Downgrading the rating because he used a "fishy" CA might motivate the website owner to switch to a CA with better standing. The bad CA will feel pressure to clear their standing.
Now that's odd, because I know those two domains. I've even requested some certificates for them myself before (never had anything odd - I think I would've noticed if there was a way to add a domain without validation), but I left the company in January 2015.
It was my coworker requesting that certificate, and I've just found - still have the access to the servers as I help them with small issues on rare occasions - that at the same date it was issued (Feb 26, 2015) he had most certainly got a validation file (idisk.su.html) and put it into idisk.su's static root.
Webserver logs are, of course, long gone so can't really tell if it was actually accessed or not, but I think when I had requested certificates myself it was a wizard-style process where one got a file to download and the only next action was to validate it, no other way to proceed.
I mean, at least he got the file and put it there, in a proper place. And it's also weird that the certificate in question (https://crt.sh/?id=29805560) had included another idisk.su subdomain (mail.idisk.su) that wasn't marked as not validated in the report (https://www.wosign.com/report/wosign_incidents_report_090420...; page 13).
I don't doubt there was a severe bug. But this leaves me wondering whenever the analysis followed was really accurate (not saying it wasn't, but still sort of curious that it could be).
To me, the ultimate question is this: if we are trusting CAs as the 3rd party entity in order to make PKI schemes work, then who's going to be auditing the "supposedly trustworthy" party?
Contributions are more than welcome.
Apple's implementation of "Rootless" while useful for other things hasn't helped by denying the ability to remove certs unless one reboots into recovery and does "csrutil disable".
DNS is distributed, not decentralized.