WoSign and StartCom: Mozilla’s proposed conclusion
docs.google.com
docs.google.com
I'm very happy to see the way Mozilla handled this incident, both with the process and the conclusion. I have a moderate trust in the CA ecosystem as a whole, but I'm glad to see that overwhelming incompetence, if not outright maliciousness, does have consequences even to big CAs.
At first though the proposed one year timeout can seem a little short given the impressive list of reported issues, but the conditions given for re-acceptance are strict enough that passing could only indicate a radical change in methodology, at which point it would only make good sense to consider a re-inclusion.
In fact if every CA could take a full code security audit and provide complete certificate transparency in the manner proposed, I think we would have reason to feel marginally safer on the Internet.
Then after a year or two, and after the CAs have learned that they need to take this stuff seriously, and yet some still get caught doing it, the browser vendors should increase the level of punishment, because those getting caught then wouldn't have much of an excuse anymore.
Can you develop please? To me it seems that the worst case would be an immediate and permanent revocation of their certs because of fraud. I find Mozilla/Google very lenient in this affair, and that's probably because I don't understand what's the problem with revoking a CA with short notice. Ok it's annoying for customers, but they just have to subscribe to a new CA and install the new cert. It's annoying but it's a security emergency. If your bank was physically guarded by a security company who has been found to replace agents with puppets in 62 Macau banks, wouldn't the head of security interrupt their week-end to guard the bank and contract a new company? If CA revocation takes customers by surprise today, it's time to start revoking certs more regularly. Heck, if you don't answer to a request from your domain provider within 15 days, your domain can even be revoked. CAs are more important than that.
The fact that they have a way to punish the CA business itself without punishing its customers is a good thing. It sends a clear message that the browsers can't be blackmailed out of punishing abuse by a CA's huge customer base. The browsers have demonstrated that they can put a CA basically out of business without impacting its customers.
If I ran a CA, I'd be much more nervous about this than I would be about them zapping the CA and all its customers.
Exactly. If they insta-revoked the whole CA, it'd hurt a pile of customers (many of which might decide that HTTPS isn't worth the hassle for them). And bigger CAs would say "eh, they can't do that to us, they'd break half the web".
Showing that they're willing to say "no new certs from this CA" means they can use that sanction against any arbitrarily large and popular CA.
> It is true that this date is chosen by the CA and therefore WoSign/StartCom could back-date certificates to get around this restriction. And there is, as we have explained, evidence that they have done this in the past. However, many eyes are on the Web PKI and if such additional back-dating is discovered (by any means), Mozilla will immediately and permanently revoke trust in all WoSign and StartCom roots.
They probably can't do it, but it's still got a better chance of success for them than staying in business for a year with no sales.
----
Edit: When I think a moment more about it, my point is silly. I realize how inconceivably impossible it is for them to avoid detection. If they sell backdated certs, one easy way to detect this would be to buy one.
WoSign/StartCom could back-date certificates to get around this restriction. And there is, as we have explained, evidence that they have done this in the past. However, many eyes are on the Web PKI and if such additional back-dating is discovered (by any means), Mozilla will immediately and permanently revoke trust in all WoSign and StartCom roots.
If the CA really goes that route, it will be clear malicious behavior and therefore a good reason to permanently ban the CA.
The only solution I can think of is to have some kind of giant database of all certificates seen in the wild that were issued by said CA, and not trust any new ones. (This may be something that can be done with Certificate Transparency, but I haven't read enough on that to be sure.) This would allow Mozilla/Apple/Microsoft to actually block new certificates.
Well I would be a little more embarrassed than that, because Wosign/Starcom were the only ones offering free SSL certificates for international domain names.
So there's no way I would pay for SSL certificates for my various personal projects and websites, but then I just couldn't get valid certificates for them anymore. Let's Encrypt might start offering them in the future, but nothing's official yet.
Insta-revocation therefore wouldn't really make this notably more painful for them -- they're walking dead at this point either way and there's a good chance they may even close shop before the deadline. All it would do is immediately put a bunch of their innocent customers in immediate pain, for essentially no gain. It might also send the message to, say, Symantec, that they can get away with anything, because no browser would risk revoking 30+% of the web instantly. Establishing a procedure that allows for executing a CA of any size puts everyone on notice.
Well, they might, unless the other browser vendors do the same. Firefox is only like 10% of the total browser market (mobile included).
Also, other root certificate programs may follow suit.
[0]: https://www.chromium.org/Home/chromium-security/root-ca-poli...
Do you have any references to back that up? I'm asking because I suspect your assumption is completely wrong.
(Based on a bunch of analytics data that I have access to, which might not be representative but still contains some very large german web properties, chrome has more than twice the market share compared to FF in germany).
http://gs.statcounter.com/#browser-DE-monthly-201508-201608
On the other hand if you only look at mobile, Chrome is well ahead of everything else:
http://gs.statcounter.com/#mobile_browser-DE-monthly-201508-...
They have to go through the normal Mozilla inclusion process and a bunch of extra hoops to get re-trusted. I think you're calling them walking dead pretty well nails it. Their smartest move right now might be to close up shop and walk away.
Given the risks that screwups have to their business, I would think CAs would VOLUNTARILY do this.
Nothing illustrates it better than @tux3 above: "I have a moderate trust in the CA ecosystem as a whole"
Trust in CA's is a bit like trusting your bank or state. Only that if you trust one bank you automatically trust all banks (unless you use key-pinning or other on top solutions that have been bolted-on afterwards).
CAs have a license to print money. What we need is a transparent Authority that is owned by the people not by some megacorp which not only issues sites but individual identity certificates. It's important to know if the CA have "Skin in the game" when they say they can protect you. (none of them do).
Disclosure: I work for The Authenticity Institute and we're quite active in that domain (also we think the way CAs are managed is a liability in the age of critical IIoT and ICS security).
Look at Diebold's numerous malfeasance issues in ATM and voting industries. If anything, they have much more to lose by voluntary audit.
Unsavory CA's might well be in the same position.
I am saving this as a reference in the event I ever need to write a technical report. This style is so much easier to read than a typical "official" report from police, the FBI, or similar organizations.
I don't have any StartCom or WoSign certificates right now, but I did in the past. It was nice to be able to get a certificate that browsers accepted, without needing to pay for it. I'm glad the landscape has changed.
We use a StartCom "MS Authenticode" certificate to sign our releases, so Windows users don't get a warning message from the various anti-malware scanners (and similar).
At first glance it sounds like Mozilla not accepting new StartCom cert's at some point won't affect that. It may snowball, but that's an unknown. o_O
ButI'm pretty sure Windows is not using NSS as its truststore for those checks. So its up to Microsoft to deal with the de-trusting (which may or may not be modular, I have no idea).
So I wish this would not affect the certificates StarCom issued for code signing.
> In addition, Mozilla will:
> add all of the Macau certificates to OneCRL immediately;
> and no longer accept audits carried out by Ernst & Young (Hong Kong).
If you don't hold the auditors responsible, this will happen again. If you do hold the auditors responsible, you might prevent some of this.
> no longer accept audits carried out by Ernst & Young (Hong Kong).
To reject audits from E&Y.... It makes me wonder about the transparency and trust we put in the auditors as being a key part of CA validation process.
When you think down this path, its why Certificate Transparency Logs make even more sense -- Yes, its still ideal that a CA operates in a "good" way, but using the Cert Logs you know everything they have signed, so a rouge actor has a limited ability to sign something they shouldn't, and as seen by Mozilla's document, they used the Cert Transparency logs as part of their evidence.
Later:
Additional fun fact: there's a decent-sized subthread on the mailing list in which it's strongly suggested that WoSign is itself quietly owned by Qihoo360, a much larger company --- somewhat like the Symantec of China.
More specifically:
(and yes, I was a paying customer)
Their rules always clearly stated the cost of replacement certificates and that this would only be waived if the replacement was needed due to their fault. As heartbleed was not a problem they caused they were well within their agreements with the customers to charge for revoking and resigning certificates.
They missed a chance at earning "good faith points" but they presumably didn't value that over the income from resigned certificates. They are a commercial body afterall.
Lets not dilute the discussion of cases where they appear to have been deliberately fraudulent by mixing in a past occurrence of them simply being uncaring.
Revocation is a critical part of a well-functioning CA system, and charging for revocations of free certificates actively puts that at risk, because it disincentivizes people from revoking potentially-compromised certificates - that is why it's morally corrupt.
> They are a commercial body afterall.
That's their problem, and putting the CA system at risk because "well, we have to make money somehow" is not even remotely acceptable.
They're also very clear that they do not intend to invalidate any already issued certificates, only new ones after a specific, yet to be decided, date and that they remain open to re-inclusion after the year's time-out and passing the normal inclusion tests. However, they rightfully set forth a requirement for some audits to take place by Mozilla appointed parties. For this I'm particularly thankful as if the auditors are allowed to keep doing this kind of hodge-bodge botch job the already strained trust in CA's is further weakened.
That said, they deserve it.
I only wish death sentences for companies participating in blatantly fraudulent activities would be issued more regularly by regulatory agencies.
Being popular does not give you the right to expect transgressions to be ignored.
I used to use StartCom and even recommend them (it was an inexpensive way to get wildcard and multi-domain certificates). Since LetsEncrypt they have far less relevance, and since recent behaviours I wouldn't trust them if they were still relevant to my needs. The one wildcard I still use (because lazy mainly) I paid for a new version of elsewhere, my other SSL needs LetsEncrypt does the job.
But it's not clear to me whether Chrome has an independent CA program. They use the Microsoft CA store on Windows, and at some point were using NSS (and hence the Mozilla certs) on Unixes. I presume they can always just additionally block this CA in Chrome, though.
Chrome does indeed use the platform CA store, but they can and do impose additional logic on top of it, such as requiring CT for Symantec, distrusting new CNNIC certs, or name-constraining ANSSI and India CCA.
Now the fact that he is an employee working on Chromium may be the reason why he ended up contributing to that part of Mozilla a bunch, but it's not supposed to be "Google gets a peer on the CA module".
Equally, Google ultimately has an interest in the security of the web platform (as well as its interoperability), as their entire business is built on it. They'd have a far harder time selling some of their products if people believed it to be insecure.
https://groups.google.com/d/msg/mozilla.dev.security.policy/...
" 1) Are the first three shareholders listed in the attached file the same companies as the "Qihoo 360 Software (Beijing) Co., Ltd.", "Beijing Qifutong Technology Co., Ltd.", and "Beijing Yuan Tu Technology Co., Ltd." entities listed in Qihoo 360 SEC reports as VIEs or subsidiaries of VIEs? [Xiaosheng]: Yes, they are.
2) Does Qihoo 360, a Qihoo 360 subsidiary, a Qihoo 360 VIE, or a Qihoo 360 VIE subsidiary, or a combination of those own or control a majority of shares in WoSign? [Xiaosheng]: Yes, the combination of those own 84% of shares in Wosign."
What is the best alternative CA that also offers wildcard certificates (preferably with a similar business model)?
- EV (green bar) certs are required to increase customer trust (it may be mostly snakeoil, but the CA system is heavily flawed and we are still forced to rely on it anyway)
- Applications where certs are used on other platforms than web servers (e.g. embedded devices, routers etc.) and 90-day renewals are not easy to implement in an automated way.
- Wildcard certs are mostly useful for convenience reasons, e.g. to easily secure a changing number of hosts within certain (sub)domains/zones (especially when they are only or mostly used in internal networks). I agree that the need for wildcard certs is greatly reduced with let's encrypt and acme.
Am I right in thinking I could generate my own certificates for any domain I wanted and have them validate in any browsers or devices that currently trust StartSSL/WoSign? Or to put it another way, would it give me the same powers as running my own internal CA but without the problem of convincing people to install my root-ca?
I assume it _can't_ mean that, otherwise people would surely be up in arms (10k to mitm anyone is scarily cheap), so could someone educate me please?
They create a new intermediate, signed by their root, just for you. You then get to ask that CA to issue certs for you - and only you.
You don't have total control over the intermediate -- as you suggest, that would let you mitm everyone.
But by having an intermediate that you effectively control, you could have apps/devices/etc that trust only that intermediate (via pinning, HPKP, etc). That prevents a bunch of the possible downsides of using the public PKI (eg, a CA mis-issuing a cert for your domains), the downsides of pinning a leaf cert (because you can always issue another one off your intermediate if you change names, etc), and the downsides of a private PKI (because stuff that trusts the public PKI works too)
You can't support Windows XP users who use IE anymore with HTTPs.
In the western world, that number is very small. It's around 1% still using XP and most of those people are probably not using IE anymore.
In china though, that number is still >5%, and I got that number personally from the metrics of a game that we just deployed an alpha for in China. I would bet that given the way the alpha test keys were handed out that the amount of Windows XP users in the general population is probably much much higher.
So what is the response if you can't support a significant portion of your user base? Well for a bunch of chinese websites the result is don't use HTTPS at all. We have seen advice that "HTTPS cases problems for users in China so we think it's a bad idea to use it". It's not a good situation.
Sure you can. Just ask a CA that has an old root trusted by XP but no longer trusted by modern browsers, and they'll issue a SHA-1 cert for you without risking to get kicked out of the truststores.
[1]: https://blog.cloudflare.com/sha-1-deprecation-no-browser-lef...
I've looked, but never found one, though that was quite some time ago. Perhaps things have changed.
This approach is beyond the ability of most to implement for themselves if they don't have support from their webserver for it.
Supporting Windows XP IE users' delusions of security is, arguably, not a desirable thing.
Not correct; you can't support Windows XP users who have not updated to SP3 yet. (Typically a pirated version which has all updates disabled...SP3 has been available since May 6, 2008)
I manage several dozen certificates; I was very pleased when StartSSL offered an automated API to work with. Despite their flaws, they offered EV certs, wildcards, and automated one-shots, and it was very convenient.
I'd gladly pay for this functionality, preferably while supporting standards-based ACME functionality... but so far it seems Let's Encrypt is the only one playing that game, and their featureset is crap for anything but their very narrow use case.
Any advice, HN?
Our API predates ACME, but we'll most likely be implementing ACME once it's finalized.
https://news.ycombinator.com/item?id=11964583
I personally immediately replaced all of my and my company's comodo certificates with DigiCert ones.
In contrast, I'm much more appalled by Symantec/GeoTrust's misdeeds (e.g. issuing unauthorized "test" certificates for google.com, badly botching the SHA-1 deprecation, cross-signing the US Federal PKI). I think Symantec is incompetent and contributes negatively to the Web PKI. I no longer issue their certificates by default, and am going to replace them with a different CA.
It's a little unfortunate that Mozilla's option here is to rely on WoSign and StartCom continuing to be honest about notBefore, or really, on Google detecting further abuse of notBefore via Certificate Transparency. Mozilla should really be participating in CT themselves so they have more options here. Is there anything the community can do to help (e.g., run more log servers)?
You don't need to rely on Google. All certs issued by WoSign since January 1st, 2015 should be on WoSign's own Certificate Transparency log from which you can download them. StartCom is logging all new certs too, but I don't know for sure if they pushed all older ones too. If you ever encounter a cert that isn't on the list, that's definitive proof that they are backdating again.
The list of certificates is too large for Mozilla to include a list of hashes in Firefox, but it might be a nice opportunity for a Firefox add-on.
Given that the behaviours being documented include falsifying data (backdating certificates to get around SHA1 retirement), I would prefer to at least use information from Google (or another third party) for the purpose of verification, rather than just relying on information sourced from WoSign/StartCom.
Of course, simply being in the log doesn't imply the cert was issued correctly, but the logs have been posted for a couple of months now and have received a lot of scrutiny during Mozilla's investigation. But the same is true for Google's log, presence in that log is also no guarantee that it was issued correctly.
It is true that, provided you have a CT log, it is append-only, and data can never leave the log file. But you need to make sure the right data is in it at some point.
https://www.eff.org/observatory
A donation funded, publicly audited, transparency report seems like a good idea to me.
So people, is there a comparable free product out there (don't say LetsEncrypt, they don't do S/MIME unless I'm mistaken)?
You can still get free S/MIME certs from Comodo.
>shawkinaw
>Goddammit. I really liked StartCom for free S/MIME certificates
Same. It came up over the last year in previous discussions when the covert acquisition began to come to light and I was forced to reluctantly dumb StartCom, but it really was a shame because StartCom's core business model was extremely sensible and doesn't seem to exist elsewhere. They essentially only charged for where there was a human time cost. So you could do automated verification (level 1) for free with decent time outs, and then upgrade to greater levels of identity verification (level 2 individual, level organization etc) building on the previous ones but in each case only the identity verification cost money, once verified you could request unlimited certs with that identity (since address ownership can be confirmed automatically). For email in particular it was quite nice.
As far as S/MIME vs PGP/GPG, it boils down to practicality in many situations.
>Why are you using S/MIME?
>It has less users than PGP/MIME, which is an impressive feat.
S/MIME has native transparent support on a number of major OS/email platforms, importantly including iOS (since iOS 5 IIRC). That helps solve the perennial general adoption problem encryption faces, ie., what happens when people using it interact with people who do not. With S/MIME there is some potential value just from signing and it doesn't require most recipients to install anything else at all.
I at least do use GPG in addition, and if Apple/Google/Microsoft/other clients all built PGP support natively into their platforms and email offerings then I'd stop bothering with S/MIME period. But as far as "how can I get many of my parents/family/friends to gain at least a little end-to-end email auth/security that they can use with minimal to zero additional effort on their part" goes S/MIME has remained valuable. Unfortunately. The entire state of email authentication in general is insanely frustrating (or even depressing), there are no great solutions right now despite the tech all being there. Use of S/MIME certainly has plenty of flaws. Right now though I've found it to still be a useful part of my toolkit and at one point I'd hoped that other places might adopt some of StartCom's innovations and ideas without the many warts. No such luck.
(Except for the part about the openssl command, this is what Exchange does: everyone joined to an Active Directory domain gets config from the AD servers, so AD generates its own CA for S/MIME certs and tells its users about it.)
Microsoft's CA services (in Windows) is actually an awesome product. You can create your own root CAs and intermediates and use the included templates or build your own to (automatically) issue certificates for anything and everything that needs to communicate (users, web servers, file servers (including encryption for data at rest), e-mail, etc.).
The CA services are one of the few things I will happily concede that Microsoft did "right" (along with Active Directory and SQL Server).
With both Chrome and Firefox no longer allowing certificates from them we can expect customers to no longer buy from them which will result in no more certificates even if Apple/Microsoft don't follow.
IIRC, it uses the OS's trust store on Windows and macOS, and NSS (so, Mozilla's trust store) on Linux. So, it's up to Apple and Microsoft to handle this for Chrome users on those platforms.
CRLSets: https://dev.chromium.org/Home/chromium-security/crlsets
HSTS Preloading: https://hstspreload.appspot.com/
more: https://www.chromium.org/Home/chromium-security/security-faq...
https://www.chromium.org/Home/chromium-security/root-ca-poli...
Mozilla's CA policy is the only major policy where almost all discussion is public (indeed, its policy requires a public commentary period), so its decision is the most visible by far. Given that the major list vendors already collaborate in the CAB forum, it's likely that MS and Apple will follow the Mozilla/Google lead here. The prior Diginotar and Comodo scenarios involved all the vendors operating in tandem.
(Not sure if cached intermediate certificates get added to the keychain - maybe that's what you saw previously?)
> Taking into account all the issues listed above, Mozilla’s CA team has lost confidence in the ability of WoSign/StartCom to faithfully and competently discharge the functions of a CA. Therefore we propose that, starting on a date to be determined in the near future, Mozilla products will no longer trust newly-issued certificates issued by either of these two CA brands.
I recommend reading the whole thing if you have time. They used some shady tactics.
Sounds very generous to me.
It's more lenient than some might want, but it avoids the decision being controversial and perhaps lessens the chance that it is seriously challenged.
StartCom is a popular CA. Distrusting previously-issued certificates would be extremely disruptive. Moreover, it would primarily punish StartCom's customers, and not WoSign, which as a business is primarily concerned with forward revenue.
You see this as leniency, but I see it as a powerful step forward. The browsers and CAs had previously been locked in a Mexican Standoff, with abusive CAs fully aware of the leverage their userbases offered them.
That's a multi-year process, unless they can get another CA to cross-sign their root, like LE did. I doubt other CAs will be willing to carry that level of risk given the reputation of WoSign/StartCom.
There's been some talk on mozilla.dev.security.policy about actively distrusting WoSign/StartCom-issued certificates for domains that have not been disclosed to CT as WoSign/StartCom subscribers (by baking the domain list into various browser binaries). That's probably the best option all around, though I'm not sure if it's going to happen (the report doesn't mention this).
"what does the punishment need to be to prevent others from seeing it, and thinking it's a risk worth taking?" is a better one.
For me, I think it should be permanently revoked.
The better solution would be to alert on all of their certs as being 'low trust'. A first step towards explicit trust belief, where reputations build slowly over time and can be severly damaged by bad behavior.
> We plan to distrust only newly-issued certificates to try and reduce the impact on web users [..] Our proposal is that we determine “newly issued” by examining the notBefore date [...] therefore WoSign/StartCom could back-date certificates to get around this restriction. And there is, as we have explained, evidence that they have done this in the past. [...] if such additional back-dating is discovered (by any means), Mozilla will immediately and permanently revoke trust in all WoSign and StartCom roots.
By far the more important element here is not that the specific corporate entity gets nuked, but that it be demonstrated to all and sundry that the CA standards have teeth. That is what will keep the bad actors from "just" doing anything to get around the problem, not psychologically-appealing vengeance.
> WoSign/StartCom could back-date certificates to get around this restriction. [...] if such additional back-dating is discovered (by any means), Mozilla will immediately and permanently revoke trust in all WoSign and StartCom roots.
What's missing, which admittedly is not Mozilla's job, is to inform any existing customers that will have to renew during the time WoSign and StartCom are suspended. If they just get an invoice and pay it or are set-up with auto-renew, they'll unknowingly get certificates that aren't valid for the remainder of the suspension (or indefinitely, if WoSign/StartCom if violates Mozilla's requirements).
StartCom is (well, was) the only competition to Let's Encrypt in the free certificate space. It is far and away the cheapest direct provider of wildcard certificates (which are impossible to get for free), unless you move into reseller territory. And even their free certificates last four times as long, and don't require the use of certbot.
Certainly, Let's Encrypt works great for a lot of peoples' needs. But for those it doesn't (and there's more of them than you might think), this is seriously bad news.
It's easy to get onboard wanting to punish WoSign/StartCom here, but keep in mind that this has the potential to screw over all of their innocent customers as well. (Future customers with the first action; all customers if the second action comes to pass and they revoke the root CA.) And screwing them could likely mean they abandon HTTPS completely instead.
Note that I am not advocating for Mozilla to give them a pass; far from it. If anything, this is just one more indictment on the long list of reasons why the entire CA system is completely broken.
I actually just recently purchased a certificate, and had my choices narrowed down to StartSSL or AlphaSSL. I am really glad I went with the latter right about now. I can't tell you how absolutely livid I would become if Mozilla ended up revoking my root CA after dropping over $100 on my certificate.
The trickier part is, it's unknown whether StartCom will backdate more certificates, triggering Mozilla to block them entirely. That could happen well after the window where you're allowed to request a chargeback. Although I do believe it's extremely unlikely that they will. Unless Google and Microsoft follow suit, such an action is just as likely to damage Mozilla as it is to damage StartCom. People who just want to access websites will not bother to understand the reason why suddenly only Firefox is refusing to let them view their pages.
Shouldn't it be under the mozilla.org domain?
A JavaScript redirect takes you straight to https://support.google.com/accounts/answer/32050.
> Because this document is extensive and contains embedded images, links and formatting, I have published it on Google Docs instead of as an email message here: https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBG...
And all they are getting is a 1 year suspension and none of the certificates are becoming untrusted. The auditors got a bigger punishment by being banned completely from Mozilla's trusted auditors.
Should just revoke them completely. Such incompetence and/or malice should not be allowed on such a crucial piece of infrastructure.
Of course, it might be nice to actually revoke them so that in the future, "will my CA be revoked" is a realistic thing to think about when choosing a certificate seller. But revocation hurts other people (website owners and visitors) more than the CA, and it doesn't seem totally obvious that it's worth it.
I'm not super convinced about the user security argument either. Sure, they backdated SHA-1 certificates and that's nasty but those certificates still expire at a reasonable time in the near future and will soon enough not be accepted by browsers at all or show up with scary UI warnings. That said I don't agree or condone what they did.
Tyro's certificate would have expired on June 9, 2016 if I'm reading the timeline right. There is nothing that would have prevented them from doing what WorldPay did and approach the CAB themselves, or become vigorously involved in the ongoing discussion (the proposal document for the process was made June 3, 2016).
On the other hand, as the IT mantra goes, failure to plan on your part does not constitute an emergency to plan on my part. The evidence is that Tyro updated its certs at the last minute, found that they couldn't get the SHA-1 they needed, and basically shopped around until they found someone who gave it to them (while lying about it!), instead of, say, making sure to request a certificate in late December to maximum the transition time available.
The great sin is not so much that they issued the SHA-1 certificate, but that they agreed not to do it, and when someone needed one, rather than bring it up with the CAB Forum, they issued one and lied about their compliance. The REALLY great sin is that they appear to have built an entire system to do the backdating, rather than applying one-offs.
Browsers can forgive CAs when they fess up to their mistakes. It's when they lie about them that they get really pissed off.
1. Your browser is no longer capable of telling you whether it's a legitimate WoSign- or StartCom-signed certificate (they behaved inappropriately, but they never intentionally signed one site's cert for someone not affiliated with the site) or a completely random certificate.
2. People clicking through SSL warnings is one of the bigger risks to user security in practice. Teaching people (especially people in their target markets) that they need to click through these warnings to get to their websites will have a very long-term negative effect on user security for a long time to come.
Bottom line: "Let's encrypt" is destroying the business of many shady CAs these days. Competition is getting harder. StartCom had an advance in this race as they adopted quickly to the new rules and the've build the best product in the market for special use cases. We - for example - rely on a lot of wildcard certs for many domains. StartCom had the product. We pay'd them $200 for all our certs and the next cheapest competitor wanted $150.000 / year for our certs. I totally get why they are getting attacked by the big players. I totally don't get why Mozilla is falling for this.
The biggest problem with the SHA-1 issuance is that they - as the report shows - blatantly lied about how this played out during the investigation and did not even attempt to go through the proper channels to get an exception from browser vendors (which other CAs did). Additionally, issuing a SHA-1 certificate to a payment processor that failed to upgrade their systems in time cannot be explained by China having a large number of XP <= SP2 users. That's just an excuse.
Regarding the TrustWave incident a few years back, it's important to understand that this happened when the rules for CAs were not quite as clear as they are now. I think this happened just around the time when the Baseline Requirements were written and were not yet in effect, and various browser policies were not as clear as they could've been about this use-case. Four years later, I have no doubts that a CA who'd give out the private key of a non-constrained CA certificate to a non-audited third-party would lose their trust status within a matter of days.
Its ok, its just a temp workaround... /s - https://tyro.com/blog/merchant-security-is-tyros-priority/
Tyro don't say when they got their SHA-1 cert from StartCom but say they needed this workaround because some of their customers still ran POS software on old operating systems such as Windows XPSP2 and that "internet security standards are moving faster than typical small merchants upgrade their systems."
> "We reached out in good faith to certificate authorities to provide a few months runway to resolve this big challenge in a way that had minimal impact on merchants."...
To me this would be ringing so many alarm bells, why would my current CA tell me they can not issue a SHA-1 cert but StartCom say they can? (I believe they got issued the SHA-1 cert after the cutoff because of the details in the document Mozilla have supplied and that we are no longer a few months into 2016 so their need for a "few months runway" was way off) Yes it would mean my customers POS systems would still function but I'm sure as hell would be asking questions about its issuance.
EDIT: Tyro have removed their StartCom SHA-1 cert from https://iclient.tyro.com/ and its now supplying a RapidSSL cert issued in May of this year but yesterday they were serving a StartCom SHA-1 cert on their iclient subdomain.
I'm not going to name the one I used (as I'm not marketing for them), but I purchased a three-year AlphaSSL wildcard certificate recently for a little over $110 (for all three years, so less than $40/yr.)
It ... absolutely defies common sense that certificate resellers are a thing; but indeed it's the very same certificate I'd have gotten had I paid $150/yr on AlphaSSL's site.
The CA model is just completely broken. But right now, our only choice is to find the lowest amount of money to be taken for if we want full HTTPS functionality. And at the moment, that's with the resellers :/
I think that's the kind of thing you should expect in any market where the cost of serving a new customer is dominated by the marketing & sales costs in acquiring that customer.
Here's a fun one I noticed: Wells Fargo and several other banks are CAs. This is idiotic. The "logic" behind PKI dictates that it's a third party identifying my bank to me. If banks themselves are CAs even that fig leaf doesn't mean much.
We have known bad actors in the pool of widely accepted CAs, right now. There's no sense bringing up obscure possibilities of MitMs that might happen absent a CA system: we have bogus certs, in the wild, today. Nuke it from orbit and teach people to pin certificates.
Not true. The third party is an operational detail to scale, there's no reason your bank is less trusted than anyone else to confirm that they're really your bank, are they?
You're suggesting that you don't trust your bank's opinion on what websites belong to them, but do trust some third party's? Even if this made any sense, the third party is doing nothing but taking the bank's word for it, if a bank for some reason _wanted_ to affirm that some random domain was EV-certified as Wells Fargo, they surely could, even if they weren't the CA -- that's just not a threat the CA model is designed against.
Yes, there is.
The list of entities I actually care about authenticity for are vanishingly small, basically just financial institutions and CAs themselves (for all other communication I don't trust who I think I'm talking with any more than I would trust a hypothetical man in the middle, so authenticity doesn't give me anything there). But for that small group, I definitely want an entity other than whoever controls their IT infrastructure to be verifying they are who they say they are.
Meanwhile, all of the dicking around these attempts at preventing largely-hypothetical active attacks have stalled simply solving the much-easier and arguably more-important issue of simply securing transport against passive attacks.
Connecting to TLS to news.ycombinator.com is nice in that I know nobody has read or altered the message in transit. The fact that a third party vouches that news.ycombinator.com is who they say they are doesn't add anything for me, because I don't trust news.ycombinator.com any more than I would trust somebody impersonating news.ycombinator.com. The CA in this situation simply complicates things and adds nothing for me.
This is at least less wasteful of time and effort on everybody's part than Comodo verifying that a specific company or person was actually involved; again, I don't trust ycombinator any more than I trust someone impersonating ycombinator, so any 3rd party verification is kind of pointless to me.
I don't understand your argument, and I think it's a novel interpretation of the CA infrastruture, I think whatever threats you are considering (that Bank of America would intentionally lie about what website is a Bank of America website?) is not something the CA infrastructure was designed to protect against or is capable of protecting against.
If authorized Bank of America staff is committed to claiming some website is Bank of America, they can get it trusted as Bank of America by a third-party CA too, can't they? I think by definition any website that authorized Bank of America agents claim is a Bank of America website, _is_ a Bank of America website. That's all it means to be "really" a BoA website, to be a website BoA intentionally meant to represent BoA.
I don't think the CA infrastructure can possibly defend against authorized Bank of America agents claiming a website is a BoA website when you think they were wrong to claim that. The CA infrastructure is meant to guarantee that the website was intentionally authorized by Bank of America to be a Bank of America website -- that's it. It doesn't even always do that securely because of flaws, but it never does any more than that.
Am I missing something?
You don't know that the message isn't read or altered in transit unless you know that your TLS connection is to the real news.ycombinator.com.
ISPs have been running transparent HTTP proxies to inject ads and other nonsense into your content. It'd be trivial for them to run a transparent HTTPS proxy to do the same - aside from the little detail that your browser would try and fail to verify the certificates provided by said proxy were vouched for by a CA.
I don't consider this is a "largely-hypothetical" attack. ISPs have been doing it for a few extra pennies of ad revenue.
I'm personally not a huge fan, but (if I'm interpreting her/his argument correctly), it'd at least be secure against a casual MITM.
* All HTTPS sites show up as trusted. Woohoo!
* All HTTPS sites show up as untrusted, people are encouraged to switch to HTTP. Woohoo!
* All HTTPS sites use trust-on-first-use, which means that we have a date and time announced when MITM attacks are particularly effective and will persist for a very long time.
* All HTTPS sites are untrusted, except for those that already have certificate pins hard-coded in the browsers' source, and excluding those that are pinning their CAs (because CAs are Broken and Wrong), which means the only websites you can access are Google's properties via Google's browser. Awesome!
* Replace HTTPS with PGP. Only people who know how to use PGP correctly get to use secure web traffic.
In scenario 5 or 4, it is easy for me (not "someone", me) to get one of those.
I still think those were good idea, but nothing is ever going to replace CAs without the support of major players such as OS and browser vendors.
How is that idiotic? Go to any CA's site and their cert will be (essentially) self-signed. There is no requirement that it's a third party signing the cert, just that it's a 'trusted' party.
Putting everyone involved out of a job and destroying whatever investments in the company they may have had, on the other hand, puts pressure on everyone involved to not fuck up next time.
When it comes to shady shit like this... I would reference the title of Metallica's first album.
edit: https://groups.google.com/forum/#!topic/mozilla.dev.security...
> "In no case were these the deciding votes."
I actually meant executing two votes in the CA/B Forum. As the connection between WoSign and StartCom was only incidentally found while investigating the other issues, I am questioning if there may be more dark sheep in the herd of CAs... we may just haven't looked hard enough. Do the Audit Requirements include checking for such relationships?
I think the voting rules are part of the bylaws (and not the Baseline Requirements), so I'm not certain if that's something that's looked into during the audits.
As a fan of firefox, I am happy that as a community, Mozilla has done the necessary ground work to reach this conclusion. However, as long as PKI remains a highly profitable business, more and more such events are going to happen.
I don't think all CAs should be trusted equally. Right now, AFAIK, my browsing experience is only as secure as the weakest CA. Hopefully, HPKP can put an end to this.
Meanwhile:
http://security.stackexchange.com/questions/86609/this-is-20...
https://www.schneier.com/blog/archives/2015/10/sha-1_freesta...
"Freestart collisions, like the one presented here, do not directly imply a collision for SHA-1"
"this work is an important milestone towards an actual SHA-1 collision"
https://en.wikipedia.org/wiki/SHA-1
"SHA-1 is no longer considered secure against well-funded opponents".
AKA, SHA-1 may not be secure against a nation state or attacker with a ton of money, but it's secure enough against for almost every site against almost every attacker. Given the reported 5%+ of Chinese browsers not supporting newer certs, I can see why customers might want a cert that gives them a lot more than nothing, though less than best-of-breed.
It's the one-size-fits-all where someone's personal blog needs to have the same level of security as the apple app store's payment system that leaves them filling a real market need. They didn't go seeking people wanting SHA1 certs, people wanting SHA1 certs that would still work went seeking someone who would provide them.
And they went seeking because the alternative is upgrading potentially millions of dollars worth of embedded kit which doesn't support newer certs, all to secure one link in a chain in which SHA1 is nowhere near the weakest link.
So yeah, the CAB chose to inflict a ton of pain and cause still-functioning hardware to be discarded in order to push a more secure ecosystem on everybody. Which is great from some perspectives, but it's environmental vandalism from another perspective, and if it pushes people back to non-HTTPS traffic for those older pieces of equipment it could cause a short term worsening of security.
(the deprecation of sha1 that is. The lying by WoSign/StartCom was a calculated risk in a business where everything is based on trust, and they lost)
I would bet the same. This seems like what you want for an exemption process: if it's too easy, people will use exemptions rather than fixing an underlying problem.
> someone's personal blog needs to have the same level of security as the apple app store's payment system
Different grades of security would not have helped in this case, because it was payment systems having trouble updating, and we put anything involving money on a high security tier - except when legacy systems get an exception.
It's not quite one-size-fits-all, because EV certificates are meant to show more trust, and most banks etc. will use those. That takes extra work, which isn't worth it for a personal site. But you don't save any work by using a weaker hash algorithm, so there's no reason for a personal blog to do so.
> the CAB chose to inflict a ton of pain and cause still-functioning hardware to be discarded
It does sound like they should have had an exemption process set up before the cutoff date, or put the cutoff further out to give people more time to upgrade systems. But using Hanlon's razor, it was probably an oversight rather than deliberate 'environmental vandalism'.
Issuing a SHA-1 certificate for one domain doesn't just put that domain at risk, it threatens the entire ecosystem. Someone requesting such a cert may have a second cert with the same hash, but for a different domain or even an intermediate, like the MD5 collision. It's not like you could avoid this by asking "are you a nation state attacker" during the application process.
I'm not the kind of person who believes in boycotting (especially in this case, where I'd be all alone it seems :-) but if I could avoid them, I would. If not, no biggie.
The suggested client, CertBot, is an EFF project, but there's a wide variety of alternatives - https://letsencrypt.org/docs/client-options/
Funny you should mention that...
Look at the SSL certificate of this site.
"It was written by multiple authors. Ryan Sleevi is at Google."
I would assume the method it was written in is of little consequence to many, just that Google Docs offer far better convenience when working in teams.
Is there any mechanism to push certificate updates to Android devices in the wild? Otherwise there's going to be a lot of devices that trust WoSign and StartCom, no matter what.
The SSL ecosystem relies on the trustworthiness of the certificate authorities. If one of them is compromised, the whole system is compromised, not just their customers. This cannot be solved by markets. Instead, it's heavily regulated.
WoSign's behavior does not specifically endanger
their customers.
[1] https://wiki.mozilla.org/CA:WoSign_Issues#Issue_N:_Additiona...
A 1-year time-out is insufficient to regain trust, IMO.
I would never let them return, absent some kind of additional (exculpatory) information)
They won't even admit to their behavior!