WoSign and StartCom: Mozilla’s proposed conclusion(docs.google.com)
docs.google.com
WoSign and StartCom: Mozilla’s proposed conclusion
https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBGv6szuSB4sMYUcVrR8vQ/preview
251 comments
My hope would be that since this method of punishing seems to be liked by most and even feels "generous" to some, the browser vendors would more aggressively start handing out "1 year suspensions" for more and more CAs that are caught doing anything even remotely like this.
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.
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.
The people saying this is "generous" are making largely irrational arguments. What Mozilla is proposing is the worst case for incumbent CAs.
> worst case
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.
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.
Immediate distrust of all StartCom certificates might be the worst case for WoSign/StartCom, but it's not the worst case for the incumbent CAs as a whole, and it's only marginally worse than what's being done already for WoSign/StartCom.
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.
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.
> 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.
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.
Doesn't the CA have one move left in this game of brinkmanship? They can start brazenly backdating their new certificates to fall into the accepted window, which would leave us right back at holding their own customer base hostage.
This is addressed in the document as well:
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.
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.
Right, and that's fine and good for WoSign/StartCom. But what if they handed out a one year restriction to a much larger CA like Comodo, or Symantec? And that CA decided to back-date their certificates? Then we still have the problem of large CAs being able to effectively ignore these restrictions because of their large userbase. As long as such CAs are able to set the notbefore arbitrarily, they can backdate as much as they'd like.
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.
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.
One more point for letsencrypt's certs short cert validity model.
So wosign's best bet might be to call Mozilla's bluff and issue backdated certs now?
They bring that up in the document:
> 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.
> 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.
Which means it's important that they try really hard to avoid being detected.
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.
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.
Really, either way, this is a death sentence for Wosign/Startcom. They're unlikely to survive for a year + all of the time and cost it would take to recertify without any revenue from certificate issuance.
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.
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.
It's worse even than that, because a substantial portion of their customer base will need to renew during the year, and will switch to new CAs. Not only do they forgo a year of revenue, but they also begin the next year with a substantially reduced customer base.
There's no guarantee their suspension will only last a year.
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.
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.
> They're unlikely to survive for a year
Well, they might, unless the other browser vendors do the same. Firefox is only like 10% of the total browser market (mobile included).
Well, they might, unless the other browser vendors do the same. Firefox is only like 10% of the total browser market (mobile included).
AFAIK, moz's CA isn't just for FF. On linux, the default "root CA" used by google chrome is mozilla's NSS as shown here[0].
Also, other root certificate programs may follow suit.
[0]: https://www.chromium.org/Home/chromium-security/root-ca-poli...
Also, other root certificate programs may follow suit.
[0]: https://www.chromium.org/Home/chromium-security/root-ca-poli...
Even if other browsers don't follow suit, 10% is enough for effectively no one to choose their certificates. When there are other, even free, alternatives, why would anyone voluntarily give up 10% of their potential users?
Browser shares vary wildly by country. For example in germany FF is still the widest used desktop browser. Including mobile probably tips it in favor of safari or chrome, but losing a substantial portion of the desktop market in Europe's largest economy will hurt you.
>> For example in germany FF is still the widest used desktop browser.
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).
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).
Not sure how accurate it is but this shows that FF is still the first desktop browser (but not for long it seems) 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-...
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-...
We just moved our stuff from Comodo to Let's Encrypt for an ancient Android version that's a few percent of a few percent. It'll happen.
> it's annoying for customers, but they just have to subscribe to a new CA and install the new cert
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.
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.
There is: the ETA for that is the end of November. See here: https://letsencrypt.org/upcoming-features/
While it will stop new customers, maybe they can keep extising by issuing them now certificates valid for 2 years.
>In fact if every CA could take a full code security audit and provide complete certificate transparency in the manner proposed
Given the risks that screwups have to their business, I would think CAs would VOLUNTARILY do this.
Given the risks that screwups have to their business, I would think CAs would VOLUNTARILY do this.
There are guidelines that have to be followed http://www.webtrust.org/homepage-documents/item54279.pdf
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).
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).
Giggle.
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.
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.
Can you elaborate? I am not familiar with the specifics of Diebold's problems and how a voluntary audit (which they could choose to keep private and use for internal assessment) would hurt them more than not knowing the risks.
A clear and detailed report. The conclusion seems both transparent and fair. It would be very difficult for many customers of StartCom/WoSign if they were immediately revoked. Hopefully this news spreads far enough that the reputation of StartCom/WoSign will generally include this information.
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.
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.
Yes, we are very fortunate to have Let's Encrypt now.
One problem - at least for the project I'm working on - is that Lets Encrypt isn't a replacement for all of StartCom.
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
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
NSS can forcibly set trust bits for certificate chains -- so in theory they could set the codesigning only trustbit.
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).
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).
Same here, I've just recently obtained a "Class 2 Code Signing" certificate from StarCom for digital sign my Windows software - as a individual software developer from China, I don't even have alternative options - I tried purchasing from Comodo, but unfortunately there process for checking individuals from out out of the US is extremely difficult.
So I wish this would not affect the certificates StarCom issued for code signing.
So I wish this would not affect the certificates StarCom issued for code signing.
[deleted]
I like this part at the end:
> 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.
> 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.
While most of the doc focused on StartCom/WoSign, I thought this bit at the end was interesting:
> 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.
> 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.
Auditors and ratings agencies and their ilk are a fundamentally broken service in our society. On the one hand they have to make money and on the other they have to be honest. The two are simply not compatible, seemingly. Eg: ratings agencies happily giving top tier ratings to mortgages back in pre 2008.
Completely Agree!
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.
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.
tomjen3(1)
Mozilla and Chrome are killing StartCom. This is huge, isn't it? StartCom is one of the more popular CAs.
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:
https://twitter.com/pzb/status/780456712562024448
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:
https://twitter.com/pzb/status/780456712562024448
Behaviours of StartCom and its owner WoSign that are against the accepted rules of the industry they work in, in industry for which trust if key, is killing StartCom.
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.
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.
By "huge", I meant:
https://news.ycombinator.com/item?id=12583390
https://news.ycombinator.com/item?id=12583390
The exact location is
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."
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."
They're not "killing" anyone. They have reasonable doubt that the CA has misrepresented the truth and engaged in practices that violate the rules set forth by the CAB and those for inclusion in the Mozilla trust store. There will have to be consequences for else it means nothing.
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.
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.
A one year timeout seems likely to tank their business. "We can't renew your cert, you'll have to go elsewhere" isn't great PR.
That said, they deserve it.
That said, they deserve it.
They're absolutely killing WoSign/Startcom. It's totally justified, but it's what they're doing.
WoSign/Startcom signed their own "death warrant" by engaging in fraud.
I only wish death sentences for companies participating in blatantly fraudulent activities would be issued more regularly by regulatory agencies.
I only wish death sentences for companies participating in blatantly fraudulent activities would be issued more regularly by regulatory agencies.
Qihoo360's browsers have awesome security: https://twitter.com/ryancdotorg/status/780470538686697472/ph...
A huge factor in their popularity is their free certificate, and now Let’s Encrypt is operational. StartCom’s free certificate always seemed like a gateway to their paid offerings, because it is so limited and awkward to use. The Let’s Encrypt product is better.
Mozilla is killing StartCom. Chrome has not announced a decision yet, although I predict that they will also distrust.
It's pertinent in this matter that one of the authors of the report works on the Chromium TLS stack.
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.
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.
Ryan Sleevi authored the report in his capacity as a peer of the Mozilla CA Certificates Module, not as a Chrome/Google employee. See https://wiki.mozilla.org/CA:Policy_Participants
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.
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.
Yes, but it begs the question why a Google employee working on Chromium is a peer of that module in the first place. It's because Google is a user, right?
It's not because Google is a user, but rather because he has contributed a significant amount to the part of the Mozilla project that that module covers. That's generally how module peers and owners are nominated / chosen.
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".
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".
It's worthwhile pointing out that many of the original Chromium developers were previously employed by Google to work on Firefox. Now, I don't know whether this is true in Ryan's case, but it doesn't seem that surprising at the end of the day.
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.
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.
The decision by Mozilla has absolutely no bearing on Chromium. Although Chromium indirectly uses the NSS root store when run on a Linux distro that uses the NSS root store, the logic proposed by Mozilla will be implemented at a higher layer than the root store, meaning Chromium won't be affected by it.
after their heartbleed extortions they really deserve nothing less
(and yes, I was a paying customer)
(and yes, I was a paying customer)
While their current/recent behaviours that are being discussed are deplorable, I don't think the heartbleed thing is as morally corrupt as many people affected make out.
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.
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.
Oh come on, I get really tired of this "well, that's what the agreement said".
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.
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.
StartCom/WoSign/Qihoo360 are killing their own CA. You can't keep lying and expect people to trust you, eventually the truth will catch up with you. Cry me a river.
Well shit. I always liked StarCom because of their approach to charge for verification (with increasing costs for each higher trust level) but not for issuing certs (while still manually checking every cert request, at least for any OV&EV cert in my case).
This entire WoSign acquisition is incredibly shady. Shortly after that some of the customer reps had chinese names, service quality declined and we got offered to become an "Intermediate CA" (StartPKI) for 10k$/yr.
What is the best alternative CA that also offers wildcard certificates (preferably with a similar business model)?
What is the best alternative CA that also offers wildcard certificates (preferably with a similar business model)?
What would being an "Intermediate CA" actually mean in practise?
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?
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?
I'm not sure about this specifics here, but this is a feature offered by some CAs:
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)
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)
What use case do you have for wildcards that you can't use Let's Encrypt or similar automated issuance? Just curious, as I've yet to hear a terribly compelling one...
Let's Encrypt cannot issue EV (green bar) certs, wildcard certs and certs with a validity longer than 90 days. While these are good features for many applications (i.e. a typical hosted website), there a lot of cases where that's not optimal:
- 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.
- 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.
I have a site that creates a subdomain for each new enterprise account and all subdomains relay on one StartCom wildcard cert. Ultimately, I can write a script to create a let's encrypt cert for each new subdomain but I've got plenty of other work on my plate at the moment.
Multi-tenant systems, for example, where each tenant gets their own subdomain. Let's Encrypt still has rate limits in place.
I'm not going to defend WoSign/StartCom's shady tactics, but the way the deprecation of SHA1 was performed puts people in a pretty shitty position.
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.
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.
>You can't support Windows XP users who use IE anymore with HTTPs.
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)
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)
> You can't support Windows XP users who use IE anymore with HTTPs.
Supporting Windows XP IE users' delusions of security is, arguably, not a desirable thing.
Supporting Windows XP IE users' delusions of security is, arguably, not a desirable thing.
> You can't support Windows XP users who use IE anymore with HTTPs.
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.
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.
Well I guess you just discovered WoSign's next business plan! Haha
OK, I'll bite: which CA, specifically, will do this? I'd sure like to keep communicating with XP after my current SHA1 cert expires this December.
And what about all the modern browsers you also need to support?
It's possible to determine whether a client supports certificates using SHA-2 by analyzing the ClientHello and use that to switch between a SHA-1 and SHA-2 certificate. CloudFlare[1] and some of the bigger sites like Facebook have done this.
[1]: https://blog.cloudflare.com/sha-1-deprecation-no-browser-lef...
[1]: https://blog.cloudflare.com/sha-1-deprecation-no-browser-lef...
And here's the technical detail of how we do it: https://blog.cloudflare.com/tls-certificate-optimization-tec....
Is there actually an open source implementation of this though?
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.
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.
You can do it with HAProxy by checking for SNI and falling back to a SHA1 cert when the extension is absent.
https://jve.linuxwall.info/blog/index.php?post/2015/10/04/SH...
A recent combination of Apache and OpenSSL has support for certificate switching based on key algorithm. You can serve an ECDSA+SHA2 certificate to clients that support ECDSA, and an RSA+SHA1 certificate to clients that don't. I'm pretty sure that all clients that reject SHA1 support ECDSA, so this should work.
You serve them a SHA-2 certificate. (In TLSv1.2 the client's supported hash algorithms are included in the handshake. Clients that don't support TLSv1.2 are probably fine with SHA-1. You can also use heuristics based on the ciphersuite to determine whether a client should get a SHA-1 certificate or not.)
Now that StartSSL is effectively deceased, is there a commercial CA that supports the ACME protocol? Or is the ACME protocol a vanity project unique to Let's Encrypt?
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?
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?
I'm the founder of SSLMate, which resells Comodo and GeoTrust certs with an automated, ACME-like API: https://sslmate.com
Our API predates ACME, but we'll most likely be implementing ACME once it's finalized.
Our API predates ACME, but we'll most likely be implementing ACME once it's finalized.
What's your take on the Comodo trademark claim on Let's Encrypt, and all the BS that ensued?
https://news.ycombinator.com/item?id=11964583
I personally immediately replaced all of my and my company's comodo certificates with DigiCert ones.
https://news.ycombinator.com/item?id=11964583
I personally immediately replaced all of my and my company's comodo certificates with DigiCert ones.
The incident was terrible, but it is not a reflection on how their CA is run. They run a trustworthy CA and employ some really awesome and competent people (e.g. Rob Stradling) who actively contribute to improving the Web PKI, such as by (co-)authoring the CAA, Must-Staple, and Certificate Transparency standards. They run https://crt.sh, which is an invaluable resource for investigating Web PKI problems (the Mozilla report and associated mailing list threads are peppered with crt.sh links). If their trademark filings had amounted to actual legal threats against Let's Encrypt I would hesitate to send them business, but it seems more like their CEO is just a giant blowhard. The good they do makes up for it.
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.
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.
Thanks for the insight!
Crazy Comodo. When that happened I resolved to never renew or buy new Comodo certs. It might be that Comodo backed away from that ridiculous plan but to be honest I don't really care - the CEO portrayed himself as a douche and it seems safe to assume they're a toxic company.
This is a very detailed investigation - the parts that appear to be new are the specific serial number patterns, the times/dates of manual issuance, and the case of the Tyro SHA-1 cert.
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)?
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)?
> Google detecting further abuse of notBefore via Certificate Transparency
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.
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.
> You don't need to rely on Google ... should be on WoSign's own Certificate Transparency log which you can download
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.
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.
They can't backdate their Certificate Transparency log without leaving cryptographic evidence behind. That's how CT is designed to work.
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.
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.
You need to rely on someone who sees certs in the wild that aren't in the CT log and complains. Chrome is capable of doing that (I don't know if it actually does), as are Google's web crawlers. I don't think Mozilla has anything that does that.
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.
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.
Why should we trust their list?
The EFF has had similar programs in the past and I generally believe them to be a reputable organization.
https://www.eff.org/observatory
A donation funded, publicly audited, transparency report seems like a good idea to me.
https://www.eff.org/observatory
A donation funded, publicly audited, transparency report seems like a good idea to me.
Goddammit. I really liked StartCom for free S/MIME certificates and TLS certs that don't expire after a month.
So people, is there a comparable free product out there (don't say LetsEncrypt, they don't do S/MIME unless I'm mistaken)?
So people, is there a comparable free product out there (don't say LetsEncrypt, they don't do S/MIME unless I'm mistaken)?
Why are you using S/MIME?
You can still get free S/MIME certs from Comodo.
You can still get free S/MIME certs from Comodo.
Trying to reply to a few parts of this nested thread at once, starting with OP:
>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.
>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.
What is wrong with S/MIME?
It has less users than PGP/MIME, which is an impressive feat.
Since many major clients support it out of the box, I'd say that at least for verification purposes, it has more users than PGP/MIME.
Wasn't Comodo on the list of bad CAs one should avoid too?
You're probably thinking of https://news.ycombinator.com/item?id=11961034
Mostly for fun.
Do people use S/MIME with the standard (web-based) trust stores? If you're using it with a small group of people you're in communication with, you can always generate your own CA pretty easily with the openssl command.
(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.)
(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.)
I am not a fan of Microsoft in any way and, fortunately, rarely have to touch a Windows box anymore. In a previous life, however, I was responsible for integrating UNIX/Linux systems in a Windows-based environment (i.e., a large organization with thousands of users).
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).
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).
I'd be interested to know what the plans are from other vendors (Microsoft, Google, Apple, ...); can we expect them to follow Mozilla's lead in taking action against WoSign?
CA root lists are generally maintained on an OS level (Oracle does maintain a separate root list for Java). Linux doesn't really have a central CA, so in practice, the root certificate list for all of Linux usually comes from Mozilla.
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.
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.
Considering I believe one of the writers of this was from Google, I guess we can assume they'll likely follow?
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.
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.
Does Chrome maintain its own trusted certificate list on any platform?
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.
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.
Yes, Chrome generally uses the OS trust store as "trust roots", however Chrome layers on additional validation and pinning in the Chrome code:
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...
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...
Chrome uses OS CA store. But, it has 'Removal of Trust' cluase which expects CA store to follow some guidelines. Starcom might be in covered in that guideline. So, blacklisting a CA store is possible.
https://www.chromium.org/Home/chromium-security/root-ca-poli...
https://www.chromium.org/Home/chromium-security/root-ca-poli...
When the story first broke, I manually untrusted WoSign's and StartCom's root certificates in OS X, instead of deleting them outright...at least I thought I did. I upgraded to macOS 10.12 Sierra this past weekend, and repeated the process. Except WoSign's certificates aren't there to begin with, though StartCom's still are. So perhaps Apple had dropped WoSign already? Would anyone else running 10.12 verify?
IIRC WoSign was never in Apple's trust store in the first place; their trust status came from StartCom cross-signing their certificates.
(Not sure if cached intermediate certificates get added to the keychain - maybe that's what you saw previously?)
(Not sure if cached intermediate certificates get added to the keychain - maybe that's what you saw previously?)
I can say +1. WoSign has never been in OS X trust chain as I hit this issue once before and had to install it myself manually. You can search about WoSign and OS X on Google and you will see that it was never there. If you found it in your trust store in the first place, there must be some shady business going on in your Mac. Also similar comments in this other HN thread: https://news.ycombinator.com/item?id=12389573
Possibly it is an intermediate certificate that is not cached yet. Does https://www.wosign.com/ give you a certificate error, and does the certificate appear in the list after visiting the site?
I had distrusted a bunch of others, too - it looks like the update flipped everything to be trusted again. Thanks for the heads up.
TL;DR:
> 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.
> 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.
A 1 year suspension and continued trust of previously signed certificates?
Sounds very generous to me.
Sounds very generous to me.
How many companies can survive a year without revenue? None I've ever worked at. Not only that, but their readmission after that year is uncertain! Mozilla gets to pick an auditor (raises hand! pick me!) that gets full access to their code. This is, I think, a higher bar than a new CA would have to clear.
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.
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.
Not only is it a year without revenue... I imagine this will devastate their revenues in future years as existing customers up for renewal during that time will likely permanently migrate to another CA.
It looks like Mozilla and Google have created a set of circumstances where the rational next step would be to wind down WoSign/Startcom and just start a new company.
Which would require creating new roots to be submitted to Mozilla's CA program, and passing the bar for inclusion of a new CA.
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.
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 should be a 1-year plus ban on principals as well.
Or buy yet another CA and continue under their name?
CAs need irreproachable reputations, anything less is absurd, like trusting your bank manager even though you know they have a gambling problem and owe money to Fat Tony. Having sympathy for their commercial corcerns is absurd.
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.
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.
How is that solution better than effectively putting them out of business?
Because of the many certs already issued and in use for ecommerce (lovely 90's word!). This will encourage those users to move to new CAs without causing breakage. If we could move towards certs signed by multiple CAs that would be good too.
"how bad will it be for the company" is the wrong question to ask.
"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.
"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.
Yeah but the existing certs are still out there. While it's great that a company is being punished, this completely ignores the fact that we have no idea what they've signed, and short of laboriously checking the trust path of every single certificate you encounter there's no way to know if the cert you're looking at at any given moment came from them or not. And worse yet, the bigger problem is there's not a practical way to actually yank all of the certificates they signed that will work for arbitrary clients who don't know anything about this process to begin with and just look for a lock in the address bar, if that.
WoSign supposedly logged all certificates they issued to various Certificate Transparency log servers, so domain owners could check those records for any mis-issuance. There probably aren't too many organizations who check CT regularly right now, but it's better than nothing.
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).
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).
It's not a 1 year suspension. It's a 1 year complete ban, then they may apply again from scratch, with extra requirements.
With a caveat, which sends a pretty strong and clear message:
> 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.
> 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.
With a "play by the rules or you're out" attached.
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.
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.
To the other observations, I'd also observe that in a world of corporate entities, there isn't a meaningful way to permanently eliminate a CA. Bad actors can always dissolve the old entity, form a new one with the same policies and any of the same people you'd like, and do the same thing. Banning the existing corporation for a year is about all you can do; the more time that goes by the fuzzier it becomes as to what exactly that "entity" is.
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.
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.
Given WoSign's history of backdating SHA-1 certificates in violation of Mozilla's rules, I wouldn't be too surprised if they reuse that practice to get around the 1 year ban, at which point Mozilla will have to consider permanently distrusting them.
They've already considered it and are including this in their proposal:
> 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.
> 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.
Would they do this out of spite? StartCom is essentially done for and has little to lose, so out of bitterness they could try to turn their customers against the browser vendors.
It's generous to the customers who currently have existing, valid WoSign or StartCom certificates. It's not very generous to WoSign or StartCom as continuing profitable businesses, because if I were paying either of these companies for certificates, I'd be looking for someone else to pay when it comes time to renew. This is exactly what you want.
I think this is very well handled on the part of Mozilla, especially with respect to existing customers.
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).
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).
Wow, this would be devastating if they actually went through with revoking their root certificate.
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.
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.
True but you're forgetting that it may be cheap to cover up shady certs they throw in, distraction. Like all the money laundering resorts in Cancun.
Surely you could have demanded a refund if you had chosen StartSSL and they sold you what turned out to be a defective product?
Good luck collecting after the company's potential future revenue has been erased.
Best recourse would be a credit card chargeback. If Paypal, probably a writeoff.
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.
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.
Just curiosity: since this report is a Google Doc, how can one know that it has been really written by Mozilla?
Shouldn't it be under the mozilla.org domain?
Shouldn't it be under the mozilla.org domain?
Being hosted where it is is particularly annoying because you can't view it unless you accept cookies from google.com.
A JavaScript redirect takes you straight to https://support.google.com/accounts/answer/32050.
A JavaScript redirect takes you straight to https://support.google.com/accounts/answer/32050.
The link was posted via mozilla.dev.security.policy
Well, here's the link to the document from the Mozilla Security mailing list: https://groups.google.com/forum/#!topic/mozilla.dev.security...
> 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...
> 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...
It was written by multiple authors. Ryan Sleevi is at Google.
[deleted]
I'm going to make a donation to Mozilla for this. Top work of public value.
Completely and utterly fail your job, lie about it and use deceiving tactics?
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.
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.
Revoking them completely would be a pain for end users of StartCom and WoSign certificates, who had no way to know that their CA was incompetent and/or malicious. But this is a great way to choke out their business by the end of a year, since they can't sell any new products.
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.
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.
Is there a compiled listing of all CA audits (good and bad) and "offenses" so a prospective customer might be able to choose a CA based on past performance rather than marketing materials?
Who cares if it's a pain? User security is vastly more important than saving companies from the mild inconvenience of changing certs.
Is user security actually improved by causing all WoSign- and StartCom-signed sites to show certificate warnings? It seems to me like it is reduced:
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.
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.
The fact that they're honoring previous certificates is a good thing. It's a demonstration from Mozilla and Google that CAs with large customer bases have very little leverage in disputes like this: Mozilla will respond with the corrective measure that causes maximum pain for the CA business and minimal pain for the CA's previous customers.
You forget things like certificate pinning which can make sites inaccessible for long durations of time if the user doesn't visit said website during this transition period.
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.
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.
Mozilla and the other browser developers' position seems to be that issuing SHA-1 certificates when they've said SHA-1 certificates should not be issued is a cardinal sin - never mind that this would break payments infrastructure. They eventually agreed to an exception process after Tyro's payments systems would presumably have stopped working if WoSign hadn't issued them a certificate.
The SHA-1 deprecation wasn't a secret: it was decided back in October, 2014. In February 2016, one provider basically said "oops, we screwed up, how can we get a SHA-1 certificate?", whereupon the answer was a one-off exception that would be notated as "yes, Symantec violated the rules, but everyone agreed to let this exception go through." This exception was converted into a more formal exceptions approval in June.
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.
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.
I think Mozilla is falling for Symantecs / other CAs propaganda here. Yes, WoSign did bad things, but those are by far not the worst things we've seen in CA wrongdoings in the last years.
We've seen certs issued for MITM attacks and security holes in the validation process of nearly every CA. (http://www.theregister.co.uk/2012/02/14/trustwave_analysis/) < they confessed issuing a cert for MITM purpose and are still part of the game.
The allegations mainly consist of:
a) WoSign didn't make transparent that they have control over StartCom. Yes, this is a thing and it should be discussed. But the main focus of this is obviously to get StartCom into this story. Where - as I understood it - there is no allegation, that StartCom itself did something wrong. At least not in the league of "we should kill that company". Transparency is important and we should fight for it. Not only in China.
b) They backdated SHA-1 certs. Obviously because not updated Windows XP machines are a thing in China. This is against code of conduct. This is bad, but I totally get the intention here. And the intention is not MITM attacks or worse (as we see a lot in CA business) the intention is not to break Chinese internet.
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.
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.
There were a number of other issues that came up during this investigation that showed that they should not be running a CA[1]. For example, they issued certificates to anyone able to control a unprivileged port (> 1024) behind a domain. They issued certificates for "root domains" to anyone able to verify control of a subdomain. When StartCom launched their issuance API, it was taken down within a matter of days due to some pretty obvious holes.
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.
[1]: https://wiki.mozilla.org/CA:WoSign_Issues
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.
[1]: https://wiki.mozilla.org/CA:WoSign_Issues
> issuing a SHA-1 certificate to a payment processor that failed to upgrade their systems in time
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.
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.
As someone who's using StartCom for several years I'm really anxious now. I may use Let's Encrypt for a few sites but not for all and I also got my email certificates from StartCom.
As far as I know there's no suitable alternative that does not cost $500+ per year, or does anyone have an advice for me?
I hate to say it, but if you need the functionality that Let's Encrypt won't offer (wildcard certificates, longer validity lengths, not wanting/needing to run certbot, code signing, etc) ... your best bet is to look for the SSL resellers.
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'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 :/
It ... absolutely defies common sense that certificate resellers are a thing
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.
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.
It's funny but I've seen the same thing with virtual carriers for mobile phones. The big name brand can charge a premium because lots of people feel uneasy going with a no-name service. Then they turn around and grab the rest of the market, the price conscious consumers, with an off-brand, avoiding damaging their big name revenue. I'm sure there's even people believing "if it costs more it must be better".
Nuke it from orbit. The whole idea of PKI is Broken and Wrong and confuses two different goals.
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.
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.
> The "logic" behind PKI dictates that it's a third party identifying my bank to me
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.
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.
there's no reason your bank is less trusted than anyone else to confirm that they're really your bank, are they?
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.
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.
> 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.
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.
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 /think/ that bandrami is trying to advocate for a DNSSEC/DANE based system for certificate trust which would put the trust in the DNS operators in lieu of the CAs, and be more about asserting "control over domain" than the "is the correct legal entity" that OV/EV (but not DV) certs claim.
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.
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.
I am having a really hard time following this argument. The CA isn't vouching for the content of your HTTPS requests.
No, the only thing the CA vouches for is that the other party is who they claim to be, which 99% of the time doesn't matter because I don't trust who they claim to be any more than I trust someone impersonating who they claim to be.
How can the CA be _more_ trustworthy as to whether the other party is really Bank of America... than Bank of America itself is?
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?
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?
I'm still lost. What do you think it is that Comodo is vouching for with Hacker News?
That the person who received the certificate from them was in control of the domain (for some definition of "control" that meets Comodo's standards) at the time the certificate was issued. I've never tried to get a wildcard from Comodo, personally, but since there's no O section of the certificate I assume Comodo didn't do anything beyond "do you control the DNS" or "do you control certain email addresses".
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.
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.
> Here's a fun one I noticed: Wells Fargo and several other banks are CA's. This is idiotic. The "logic" behind PKI dictates that it's a third party identifying my bank to me. If banks themselves are CA even that fig leaf doesn't mean much.
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.
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.
OK, so what do you want to happen starting tomorrow morning?
* 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.
* 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.
There was a good start of an answer to that in Perspectives [1] (and later Moxie's Convergence), but sadly those projects are technically dead now.
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.
[1] https://perspectives-project.org/
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.
[1] https://perspectives-project.org/
#3, with HKPK and a transition period covered by CAs, is not entirely unreasonable and even offers some real advantages. The changeover doesn't need to take place at the stroke of midnight.
You could engineer #3 to work, but the big trouble is that occasionally someone will reinstall their web server from scratch (on purpose or as part of disaster recovery), lose the key, and expect not to lose their website permanently. I have yet to see any organization that deals usefully with changed SSH keys and communicates them properly instead of "oh yeah, we changed that, delete it from known_hosts and it'll be fine", and organizations that use SSH are more likely to know what they're doing than the average Internet site (in fact I count MIT's CS department as one of the guilty parties). An internet-wide equivalent of "yeah, just delete example.com from your known_hosts" is essentially an internet-wide announcement of "yeah, plz start MITMing example.com".
Mostly #5, with some of #4. We have known bad certs in the wild (including for Google) so the "security" PKI offers us is just theater. I think the theater should end, which might actually get people off their asses to fix the real problem and stop outsourcing it to shady rent-seeking companies.
If the security the CAs offer is "just theater", go spoof DNS and phish Bank of America logins; you should be able to trick users just by rolling self-signed certificates.
You do know that BofA is one of the organizations with verified bad certificates in the wild, right? This isn't just a theoretical worry. That's why it's "theater": we know that right now there are valid but bad certificates for a depressing number of entities.
It's a shame it sounds like there are no legal avenues for penalising the individuals behind this. Actions like this ought to be criminal. In the end, if the only penalties are directed at corporations involved it isn't much a of disincentive to state actors or others with sufficient resources who want to game the system.
Individuals? This sounds like a systemic organizational issue. I'm sure we can drum up a few scapegoats, but I'm not sure if that'll be terribly effective in fixing the incentives.
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.
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.
I am both surprised and immeasurably pleased at the sight that "too big to fail" isn't (yet) reality for CAs.
When it comes to shady shit like this... I would reference the title of Metallica's first album.
When it comes to shady shit like this... I would reference the title of Metallica's first album.
I remember that there was some talk about double voting (WoSign and StartCom not being separate entities, but voting with two votes) in the mailing list. Is there a reason as to why this event hasn't been included in the document?
edit: https://groups.google.com/forum/#!topic/mozilla.dev.security...
> "In no case were these the deciding votes."
edit: https://groups.google.com/forum/#!topic/mozilla.dev.security...
> "In no case were these the deciding votes."
The issue you're describing is a concern for the CA/B Forum, not really all that relevant for Mozilla/mozilla.dev.security.policy. That being said, the CA/B Forum seems to be discussing the issue[1].
[1]: https://twitter.com/sleevi_/status/780454860676149248
[1]: https://twitter.com/sleevi_/status/780454860676149248
Thank you, though the Qihoo relationship is not what I was referring to.
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 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?
That's in all likelihood the same issue - Qihoo de facto owning two CAs who currently cast two separate votes in the CA/B Forum. Not sure if it would be a concern otherwise (i.e. if Qihoo were to own just one CA and not disclose that fact, I don't think that's relevant for the CA/B Forum, leaving aside the problem that they're also a member as a browser vendor ...)
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.
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.
It's in the wiki
https://wiki.mozilla.org/CA:WoSign_Issues
https://wiki.mozilla.org/CA:WoSign_Issues
Could you please refer to the actual Issue? I can neither find anything related to the CA/B-Forum voting fraud nor to the yet unresolved Qihoo relationship.
Is there a governing body or regulatory authority which looks over the process followed by CAs ?
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.
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.
Shoot, I just renewed two of my domains with the free StartCom certs on Friday... Even though I'll likely have minimal-to-no impact, I'm still very disappointed with this.
I’m glad that I have been distrusting Startcom on all my devices since early 2014. Time to do the same for Wosign.
How can I check if I am using one of their certificates?
While I agree that they did the wrong thing and WoSign/StartCom should be punished for lying, the whole sha-1 deprecation thing is very black and white. Others have successfully gained "exemptions" to do precisely this, and it's an interesting question whether it would have been easy for WoSign to get those same exemptions if they'd just asked. I bet the answer is "possible but not easy".
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)
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 bet the answer is "possible but not easy".
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'.
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'.
> 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.
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.
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.
So I don't like Let's Encrypt, if Mozilla "kills" WoSign/StartCom, what are my options if I want a cert for free?
What exactly don't you like about Let's Encrypt? Besides Let's Encrypt, your other option is paying for a cert from GoDaddy or something. My two cents: don't give business to Comodo, given their horrible track record of sleaziness (https://en.wikipedia.org/wiki/Comodo_Group#Controversies).
My two cents: don't give business to Comodo, given their horrible track record of sleaziness (https://en.wikipedia.org/wiki/Comodo_Group#Controversies).
Funny you should mention that...
Look at the SSL certificate of this site.
Funny you should mention that...
Look at the SSL certificate of this site.
There is globalsign and AlphaSSL....
I don't like the EFF, but I guess I will have to use Let's Encrypt if there's no other option.
As much as I don't agree with you... Let's Encrypt isn't actually an EFF project, or even majority EFF funded. One developer is provided by the EFF, one of the board members is from the EFF, one member of the technical advisory board is from the EFF, and there is a sponsorship from the EFF. The organisation has various other employees, board members, and sources of funding. Even in the genesis of it, it involved three non-EFF people and one EFF person.
The suggested client, CertBot, is an EFF project, but there's a wide variety of alternatives - https://letsencrypt.org/docs/client-options/
The suggested client, CertBot, is an EFF project, but there's a wide variety of alternatives - https://letsencrypt.org/docs/client-options/
If I might ask, why don't you like them?
They are a political organisation and their ideas conflict with mine. I don't keep a strong boycott on them, but I don't want to support their products, that's all.
I'd be very interested to know which of the EFF's political positions you object to, but it appears pretty clear you're avoiding answering that question...
I don't see how that's relevant, unless the goal is to invalidate his(?) dislike of them by claiming the political views that dislike is based on are wrong and stupid.
The goal was to find out more. Having never encountered an anti-EFF person on here (or anywhere, that I can recall) I was interested in the answer.
I don't think net neutrality is a good idea. I also have far-right ideas, while they have repeatedly expressed themselves to be liberal.
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.
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.
Fair enough. It's not often I see anti-EFF folks, so I appreciate the elaboration.
If you write off Let's Encrypt, I think your options will be limited to "pay for a certificate".
Any other CA?
[deleted]
why is this google docs ? why is this not atleast a markdown file in github ?
From tptacek:
"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.
"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.
This is a working draft of a findings document that's being actively edited. Google Docs allows for realtime cooperative collaboration, with nice features like chat and annotation of documents. There are a few other collaborative editing systems out there, but they tend to have more hitches than google docs'
If the CA market were efficient this would lead to bankruptcy of this company since there's no reason to chose them over the many competitors and many reasons to distrust them. Though of course the market is not efficient. I keep wondering when the Communist Party of China is going to make its heavy handed presence felt in the CA world.
Even after this disclosures, a fully informed, rational agent would still choose WoSign if their price and service were the best. This is because WoSign's behavior does not specifically endanger their customers.
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.
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...
The browsers will distrust the CA. Which will, in all likelyhood, lead to their bankruptcy.
Will they? Still gotta wait for Google, Microsoft and Apple.
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.
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.
In practice, nobody is going to buy a cert for general web use which doesn't work for Firefox. They could scale back drastically and focus on internal certs and certs for other uses, but that might not be enough to keep them afloat, especially with the reputation damage from this.
Chrome doesn't have their own certificate store, instead they use the platform's certificate store with some logic layered on top (e.g. requiring new Symantec certificates to be in the certificate transparency logs). So an update to the Chrome app on Android could implement Mozilla's plan, or something even more extreme.
Corporate personhood is an American thing, but if the CA can't perform their most fundamental function (certifying accurate information), isn't that the best possible case for the corporate death penalty?
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!
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!
Corporate personhood is not an American thing. It appeared in the UK in the 1800s and it's now common across the world.
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.