WoSign's secret purchase of StartCom: WoSign threatened legal actions
percya.com
percya.com
Both should be revoked.
EV certs are quite useful for special sites like banking though.
The certificate pinning is valuable in terms of preventing MITMs by rogue CAs, but the EV itself doesn't seem to really add much.
"Make sure it says <company name> in green at the top" is much easier than "ok now check any intermediary certs, and of course make sure they have the right fingerprint"
You never control a domain - ICANN, your TLD registry and your immediate domain registrar do. So, technically, it's just replacing one trust vector with another.
However, given that we don't have a proper crypto in DNS (not even DNSSEC which many don't like and urge to abolish), it would be terrible. Anyone who can feed you spoofed DNS responses (i.e. starting from a cafe hotspot) would be able to impersonate just anything.
Then don't use DNS if you can't trust it? You have to trust at some point. Or create your own infrastructure and convince others to trust you, if you want more than a private network.
> Anyone who can feed you spoofed DNS responses
The tendency goes towards running your own local DNS resolver. It was not possible in the 90s, but since then both the network and computer got a lot faster and smarter.
DNSSEC has also evolved quite a bit and is the best we will get for long time. I really encourage to have a look again before dismissing it outright.
Same with CAs, but I believe it's easier to distrust a rogue CA than a rogue name registry. I mean, if there's a news that some .example TLD is in bed with NSA, Chinese government and Russian FSB - there isn't much we can do about that, isn't it? And I guess most businesses won't go as far as changing their domain name.
At the same time, on most devices I saw, distrusting a CA wasn't terribly complicated. And can be done by a browser or OS vendor, with a version upgrade, as well.
> http://blog.easydns.org/2015/08/06/for-dnssec/
Thanks for the link. Looks like an interesting reading.
As a bonus, determining the shadyness of a domain based on the TLD is something even many regular end users can be capable of, because it is so visible. End users never look at SSL CA chains, but the TLD is visible front and center.
Eventually it wouldn't surprise me if that included cutting out the URL completely for EV and just showing the validated name. It also wouldn't surprise me if the TLD gets greyed out and diminished compared to the domain below that sooner rather than later.
But in a way, I hope this makes everyone trust the whole CA/DNS system even less, and they start coming up with real, more decentralized and trust-less systems.
Until then I am very much against start mistrusting DNS as a precautionary measure based on FUD.
> they start coming up with real, more decentralized and trust-less systems
Sounds intriguing, how should this work? There are some ideas out there, but they all have major drawbacks. So it will take time and a real, present threat for people to start using it regardless of the drawbacks.
Not only that, but DNSSEC+DANE does this without eliminating CAs. It can't, because browsers can't rely on DANE in the real world, for technical reasons.
Previous discussion: https://news.ycombinator.com/item?id=12383795
That's not new; it just makes plain what has always been the case. Better to have it out in the open, IMO.
The legacy non-CC TLDs (.COM, .NET, etc.) are essentially US territory for historical reasons -- .COM should really be ".CO.US" but the latter will probably never catch on, and the ship has sailed at this point -- and anything under .UK is the UK's, obviously. If you don't want your DNS controlled by a FVEYs country, probably best not to use a TLD that's under one of those countries' control.
Setting up something in .COM that's likely to be objectionable to the US government is as unwise as setting up something that the Chinese government is going to find objectionable in .CN DNS space.
The idea that the Internet would ever somehow transcend nations, when it relies on infrastructure that lives in the physical world which is dominated by nation-states, was a naive piece of 1990s idealism. The fact that the Internet lets you basically choose your jurisdiction is a great thing, and shouldn't be undervalued. I don't think there has ever been a time when a person in the US could so easily set up a publication that's protected under the laws of (say) Finland, or Russia. (Of course, they do so at their own personal peril, if they live in the US; again, there's no escaping nations, just choosing between them or hiding.)
I am not totally sold on the DNSSEC+DANE concept, but the fact that it admits reality as it exists on the ground, which is that the Internet exists of and in the world and not above it, does not strike me as a particularly compelling criticism.
If we adopted DNSSEC+DANE --- and, make no mistake, we have not adopted it --- this status quo would no longer be the case. The DNS hierarchy has no trust agility. You can't burn .COM; if you do that, you break the whole Internet. The browser vendors can, will, and repeatedly have torched misbehaving CAs, and forced still more into Certificate Transparency programs. That's a capability we actually have today, without anyone doing anything, that we would lose in DANE-land.
This isn't a complicated argument. I'm surprised it's stayed live on this site for so long.
There are lots of other dealbreaker problems with DNSSEC! But this is the simplest of them.
I'm all for trying to reduce the need to trust one's government, but I think this is getting out of hand.
Currently, if you really want to trust the little https lock icon, you need to trust your government, pretty much everyone else's government, a whole lot of non-governmental companies of which many are demonstrably untrustworthy, and anyone who can hijack internet traffic well enough to spoof domain validation. And you need to trust everyone with control over DNS, because they can very easily spoof domain validation. That's a lot of people, any of whom can force a certificate.
With DANE, you need to trust the DNSSEC roots and the hierarchy from the roots to your domain. That's it.
So the argument that Verisign and your registrar (and presumably your government) can potentially defeat DANE is an argument against a ridiculous straw man: Verisign and your registrar can defeat the existing system just as easily.
At least with DANE, a whole bunch of other governments, registrars, AS operators, etc can't also impersonate your web site.
Of course you can argue that HPKP is not quite there yet, but that is also true for DNSSEC in general, and even more true for DANE. If we somehow, against all odds end up in a situation where DNSSEC is actually widely deployed, it wouldn't even be a bad thing for the domain validation process in general - preventing at least some attack vectors, though I'd argue it's not worth the cost. However, it should never be a replacement for efforts like certificate pinning, Certificate Transparency, etc.
IMO we would ideally use DANE and HPKP with CA roots kept around for legacy clients.
Every HPKP-enabled browser functions as part of a global surveillance system monitoring certificate issuance.
This works because under the TLS CA hierarchy, we have trust agility. When a CA screws up badly, they can be limited by the browsers (Chrome has repeatedly shown themselves willing to do that), or removed entirely.
DNSSEC+DANE gives us no trust agility. You cannot revoke .COM without breaking the Internet.
Run a stub DNSSEC validator and no one can feed you spoofed DNS responses if they're signed. DNSSEC doesn't require that validation only happen at the recursive server.
If you want DNSSEC to actually secure you, you need to reject any DNS answer that should have a signature, but doesn't. This means sites not working if there is a slight mistake upstream. Unless this shit becomes really rare, it seems unlikely people will accept this.
If you ignore this, you are vulnerable to anyone who can spoof DNS and refuse to server RSIG records.
If a zone is DNSSEC signed and I query its records regularly(i.e. they stay in the cache) it would be very hard to spoof their records. If I also use a recursive resolver that does DNSSEC validation(e.g., 8.8.8.8) it's even harder. I'm not quite willing to say it would be impossible, but AFAIK no one has shown it to be possible.
There's a well-known key for the root, which vouches for the key for the .org TLD, which vouches for the key for the example.org domain, which vouches for the A/AAAA/TLSA RRs for www.example.org.
What part of the chain can the café hotspot break?
DNSSEC was designed in the mid-1990s, before protocol designers understood crypto, and it was carefully designed to minimize cryptography. Several other bad attributes fall out of that decision as well.
By that logic, because someone could write a browser that will accept invalid certificates and/or show everything as secure etc, TLS in general is fundamentally broken so we should never use it.
A bad implementation isn't reason to abandon the concept.
Also: Unless you need to support fucking ancient client devices/user agents, I urge you to drop SSL (and upgrade to as recent a TLS version as possible)
Re-read what I wrote, and what I replied to.
A lot of DNSSEC/DANE detractors claim that its effectively useless and unusable, because currently a lot of DNS stub resolvers (e.g. home routers) don't do DNSSEC verification.
My response is that you can use the same argument to make anything useless, if you introduce a terrible implementation.
Let's try a different example separated from certificates to make it clearer:
IE6 was a fucking terrible web browser as far as web standards go. Therefore, web standards are useless and should be abandoned.
If you want better than that, you can't use a stub resolver. You have to embed an entire recursive cache server in every endpoint.
And this conversation we're having about distrusting WoSign? We couldn't even have it about abandoning .com.
People should look into Moxie's thoughts on "trust agility" where he specifically addresses DNSSEC/DANE and recommends against it. It's a great read.
Now, after the whole WoSign controversy I'd be reluctant to ever use their services again, but I just wanted to point out that I was a happy user and later customer (I paid for wildcard certs) for years without any issues.
Just should've kept pestering him, I ended up paying twice the regular fee and were allowed to print as many class 2 "verified" certificates as we wanted to. By their own ToS we shouldn't even have been class 1 verified, as a whole team of admins was "impersonating" our CEO for years.
https://news.ycombinator.com/item?id=12391308
> How? I've got no way to judge the security / responsibility of any CA. (...) You can't blame the CA customers for this.
To which I answered:
> One sign is that if Symantec has issued rogue certificates, and Google publishes the problem, then it's time to leave.
I'd say it's valid for StartSSL now as well...
The other thing I didn't realise until I read the thread is that this situation seems to be currently unfolding - there are posts on the thread from Richard Wang dated September 2nd.
And no, Let's Encrypt is not a full substitute unfortunately, as it offers only SSL certs. GPG has poor mobile and native platform support compared S/MIME. So I do think it's a bummer that StartCom is toast.
[1]: https://news.ycombinator.com/item?id=11107740
Edited to add: just to be clear, they absolutely had their flaws all along too, primarily in terms of charging for revocations which rightly earned criticism. But I still wish a better organization would take the good bits and improve rather then the entire thing vanishing into the annals of history. I feel like we're really treading water when it comes to authentication, despite it being an ever more critical part of life. All the math and basic tech needed to solve it correctly and in a user friendly way has been around for at least a decade or two at this point, yet most people and organizations still send messages with no real authentication (which in turn is the direct root of much spam and scams), password use (and resultant problems) is still near universal standard practice, etc.
I have now dropped my ongoing EV verification with them (has taken 7 months so far!) in favor of CertSimple, and we've also moved all non-EV to LetsEncrypt/AWS.
StartCom provided GNOME with a free account which can create certificates (including the wildcard ones and so on). Those are pretty much mandatory in certain cases (secure Bugzilla attachment hosting).
But with ACME, the need for wildcard certs is strongly reduced. If you don't need dynamic, on-the-fly subdomain creation, it's trivial to have Let's Encrypt generate certs with all the subdomains you need (especially now that the limits are much higher than during beta).
It also removes the complexity of having to deploy let's encrypt certificates every X months without storing the LE's account key online. But if they release certificates for anybody claiming to be you there is no advantage in this area.
So as much as people think Startcom is scummy, they are actually pretty decent people. They're also quite secure. So YMMV.
This was long before the alleged sale to china though, maybe 5-8 years ago? I forget.
LetsEncrypt's certs are not trusted on Blackberrys (including BB10 devices), and because Blackberry's big thing is 'a secure OS' there's no way to side-load[1] a root cert.
Although dwindling rapidly - there's still some big business out there that are still issuing Blackberrys to it's users.
My main home server is behind a StartCom cert... and I use a BB10 device - so no LetsEncrypt migration for me :(
--
[1] Happy to be corrected on this, If I'm wrong!
> Although dwindling rapidly - there's still some big business out there that are still issuing Blackberrys to it's users.
What business are you in that Blackberry users are a factor? What percent (or total number of users) would be impacted?
Only time I've seen a Blackberry in recent memory is as a stock image on a "Why RIM failed..." article.
My Blackberry is personal though (I love hard keyboards!).
If you can afford a home server, $9 is cheap. It's way cheaper than what StartCom will charge you to revoke your cert if you ever need to (security breach, the next heartbleed, etc.). In fact, StartCom's terrible handling of heartbleed is what prompted me to switch from their free-but-expensive certs to Namecheap/Comodo's paid-but-cheap service.
Enterprises love to MITM SSL (and may also have their own CAs to issue certs for internal services). Even Chrome ignores cert pinning if the CA is user-installed for this reason.
As an aside, I found this amusing: https://community.letsencrypt.org/t/inclusion-of-isrg-root/9...
Lesson of the day: public perception of customer support is important. Rude support worse than no support at all. Noted.
The GUI way: https://wiki.mozilla.org/CA:UserCertDB#Deleting_a_Root_Certi...
The CLI way: http://unix.stackexchange.com/a/285831
Chrome/Chromium: search "certificate" in settings to get to the certificate manager, edit trust settings for certificates.
That certainly makes the Nougat taste a bit sour. And Chrome doesn't even support ad block on mobile.
Let's hope Firefox gets its act back together.
Without this, it would be quite difficult to ensure you can serve a customer a valid certificate. At the same time with much more cross-signing, trust would be established much better.
sigh
I call for a detailed investigation over WoSign's purchase of StartCom
and the current status of StartCom. If StartCom is deemed untrusted in connection with WoSign,
it should be revoked as well.
I further call for all current users of WoSign or StartCom to switch to Let's Encrypt as soon as possible.
First off, it's impractical for all StartCom/WoSign customers to switch to LE because LE doesn't offer wildcard and EV TLS certificates, neither do they offer certificates that are valid more than 90 days.Second of all, there are 175 root certificates[1] (close to a hundred CAs) trusted by Mozilla, why does this blogger targets the one and only CA in China; go above and beyond digging into private business deals to prove his point and trying so hard to gather up public support to revoke WoSign's root certificates?
I mean, sure WoSign was pretty bad in those incidences of certificate mis-issurances and have had some really shitty practices exposed (I suspect incompetence might also contributed), but is WoSign the ONLY one out there who does these shitty practices in the CA business? We don't know, until someone's look into it. But publicly shaming a single CA doesn't make all of us securer, rising awareness and promote security best practices do.
PS: if you read the rest of his blog posts in Chinese (resource links ), you would most certainly agree that the blogger is A) knows Chinese really well and B) is a political dissident. So is there any hidden motive of why the blogger did what s/he had done? Personal revenge? You guess is as good as mine.
Even though you're probably correct, it's irrelevant. Every CA should be able to stand up to whatever scrutiny people choose to put them under. Just because this person is not targeting all of them does not make what he finds LESS valid.
If he's making stuff up, then yeah, that's obviously it's a problem.
To Straw Man you, it's crazy to say "I'll ignore these facts because the messenger has a bias".
1. Open Keychain
2. Search for Startcom (3 results)
3. Double click each certificate
4. Open Trust section (expand small arrow)
5. Select "Never Trust" for the first option.