WoSign's secret purchase of StartCom: WoSign threatened legal actions(percya.com)
percya.com
WoSign's secret purchase of StartCom: WoSign threatened legal actions
http://www.percya.com/2016/09/wosigns-secret-purchase-of-startcom.html
102 comments
I have just read through the mailing list thread referenced in the article, and with the important caveat that I am not an expert in this space, it seems that WoSign has failed to comply with the basic requirements a CA has to meet to be trusted by the major browsers. And compounding these failures, Richard Wang (apparently the managing director of WoSign) either doesn't grasp, or is intentionally trying to minimise the severity of the failures. Compounding the situation more, it seems that WoSign may have acquired StartCom. If true, this seems to be a much larger story, because of the (probable but not yet proven) concern that any failures WoSign is exhibiting, StartCom will exhibit too. Also Richard Wang seems to want to keep the nature of the relationship between WoSign and StartCom as vague and secret as possible. This is concerning because, in the case of CAs in particular, if they haven't done anything wrong, why are they trying to hide it?
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.
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.
The whole CA system should be abolished. The only thing needed is certificates for domain control, as LE does. We need one or two non-profit organizations for that who do that work transparently. Remove the market from where should be none.
>The only thing needed is certificates for domain control, as LE does
EV certs are quite useful for special sites like banking though.
EV certs are quite useful for special sites like banking though.
Why? As long as there's a single rogue CA that lets people print EV certs without due diligence, the whole system is a farce.
Not with CT and pinning.
At that point why have EV instead of actually doing real security and prompting the user to verify the certificate (and remembering what they approved)?
I don't think my mother knows how to verify the certificate and certificate chain.
Unless your mother knows not to go to a site without an EV certificate, it doesn't really matter that much.
The certificate pinning is valuable in terms of preventing MITMs by rogue CAs, but the EV itself doesn't seem to really add much.
The certificate pinning is valuable in terms of preventing MITMs by rogue CAs, but the EV itself doesn't seem to really add much.
> Unless your mother knows not to go to a site without an EV certificate
"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"
"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"
What we have is DANE and 0 nonprofits. Instead you add RRs in the domain (which you control, right?).
> domain (which you control, right?)
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.
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.
Technically, it's replacing two groups of people you have to trust with one, since gaining control of a site's DNS is sufficient to issue certificates for that sites under the current system.
> You never control a domain
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.
http://blog.easydns.org/2015/08/06/for-dnssec/
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.
http://blog.easydns.org/2015/08/06/for-dnssec/
Among many other problems, DNSSEC+DANE permanently concedes .COM, .NET, .ORG, .CO.UK, and .IO to the FVEY Intelligence Community --- the TLDs are controlled by world governments, as we all know from watching the DOJ use that control to attack file sharing sites.
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
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
> Among many other problems, DNSSEC+DANE permanently concedes .COM, .NET, .ORG, .CO.UK, and .IO to the FVEY Intelligence Community --- the TLDs are controlled by world governments, as we all know from watching the DOJ use that control to attack file sharing sites.
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.
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.
If a site deploys certificate pinning via HPKP, you don't need to trust anyone other than whoever the site deems trustworthy. So why bother with a new system that might be an improvement for a small subset of the trust problem (and comes with a huge set of other problems) when we already have a system that's supported by a large number of browsers, is in use by a number of high-profile sites and has shown that is effective against compromised CAs in the past?
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.
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.
I don't think that I or anyone else has suggested that DANE is in any respect whatsoever a replacement for HPKP. DANE could partially replace or augment the CA system.
IMO we would ideally use DANE and HPKP with CA roots kept around for legacy clients.
IMO we would ideally use DANE and HPKP with CA roots kept around for legacy clients.
The threat model you described did not take HPKP into account at all, and the existence of HPKP has a large effect on the question of whether DANE is worth the hassle (and the problems it comes with).
HPKP doesn't really solve these problems. It requires initialization, so a naive browser isn't protected at all. It also makes a bunch of smaller operators nervous because, if they lose their keys, it's game over. DANE gives a happy middle ground where you can easily re-key and only a small number of third parties can potentially tamper with the keying.
No, that is only half the HPKP story. The other half is that when a pin breaks in a browser, the browser can report it. Your browser might not have a certificate pinned yet (though: for the most important sites on the Internet, it does, because they're preloaded). But hundreds of thousands of other browsers do.
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.
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.
> Among many other problems, DNSSEC+DANE permanently concedes .COM, .NET, .ORG, .CO.UK, and .IO to the FVEY Intelligence Community
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.
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.
It is simply not true that in the status quo, setting up a site under .COM gives the USG access to your TLS keys. As long as you're pinning certificates, governments can't generate fake certificates for your site without burning the CA that they suborned.
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.
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.
> Then don't use DNS if you can't trust it?
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.
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.
If you can't trust your TLD operator, then you should definitively change your domain name. Otherwise they could fake their NS query responses for your domain at any time and obtain certificates from other CAs during DNS/HTTP validation. You've already lost if your TLD operator is out to get you. Pick a more trustworthy TLD next time.
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.
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.
Modern browsers have been hiding more and more of the URL. Yes, the domain with tld is still visible for now, but the trend is to cut out anything that might confuse a user.
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.
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.
No way. They might as well remove the entire URL bar then. It'd be way too easy to phish if you couldn't tell the difference between .com/.net/.org, never mind all the ridiculous new TLDs like .plumber and .guru.
Mobile phones already don't show the URL bar most the time.
I don't know if adopting DNSSEC at a time when Russia and China will control ICANN, too.
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.
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.
> when Russia and China will control ICANN
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.
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.
How?
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?
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?
Any of them, since DNSSEC validation doesn't occur in stub resolvers, but is instead delegated to the caches (the "DNS servers" you or DHCP configures).
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.
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.
> Any of them, since DNSSEC validation doesn't occur in stub resolvers.
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.
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.
I don't understand this objection. No, as a fact, DNSSEC resolution happens at DNS servers. No browser does DANE at all (the two that tried --- Firefox and Chrome --- rescinded their support). But when they do, they'll be using a stub resolver just like everyone else, because that is how the protocol is designed.
In what ways is TLS fundamentally broken? (Not arguing, I really want to know. We're looking at moving to it from SSLv3 as I write this.)
Edit: TL;DR: I'm not saying TLS is fundamentally broken.
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.
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.
It's not that stub resolvers don't do DNSSEC validation. They can't. They get a single bit in the header from their upstream recursive cache telling them whether validation succeeded or failed. That's it.
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.
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.
Exactly this. These days we even trust our neighbours accepting their BGP routing advertisements, which are easily modified to bring traffic to our infrastructure and intercept it. It happens every day all over the world...
> Anyone who can feed you spoofed DNS responses (i.e. starting from a cafe hotspot) would be able to impersonate just anything.
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.
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.
That isn't going to work for the general public though. Not because it is too difficult to set up (that can be fixed by sane defaults). Instead the issue is dealing when you can't get DNSSEC responses.
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 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.
DNS records tend to hang around in caches, and people query the same RRs regularly. Thus, it's pretty hard to spoof a RR that you're regularly requesting. This doesn't help for those zones that are not DNSSEC enabled, but there's nothing you can really do about that.
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.
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.
What's funny about this idea is that if your site is in .COM, even in DANE, your CA is Verisign --- the oldest and best known of the SSL CAs.
Also, Verisign the CA works for Verisign, while Verisign the TLD operator (.com, .net, .gov) works for the US govt.
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.
https://moxie.org/blog/ssl-and-the-future-of-authenticity/
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.
https://moxie.org/blog/ssl-and-the-future-of-authenticity/
Yet, StartCom's free certificates were the reason my sites have had SSL certificates for years.
I moved my personal site from StartSSL (which I had used for years) to Let's Encrypt a few months ago. It was really painless, and I recommend it.
Not that positive if StartCom also gave others free certificates for your sites.
My experience with StartCom was that they were incredibly responsive (Eddy himself answered some of my customer support tickets, sometimes within 20 minutes late at night) and they manually checked every single certificate request and even refused one. I requested a certificate for a company website and they wanted a letter of agreement from the CEO. Went with a paid DV certificate since that was too much effort.
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.
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.
> I requested a certificate for a company website and they wanted a letter of agreement from the CEO. Went with a paid DV certificate since that was too much effort.
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.
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.
Someone asked 2 days ago how customers could be careful about their CA being revoked:
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...
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...
I reluctantly stopped all usage and recommendation of StartSSL last year after concerning information came up about a shift to Chinese ownership/control due to their hosting by Qihoo 360 (previous discussed on HN [1]), which went poorly in the context of both their lack of transparency and their long standing insistence that certain keys be generated in the browser rather then a user supplied CSR. But it really was reluctant because their actual model was fantastic and how I desperately wish other CAs operated. They charged only for the actions that actually take human time: manual identity verification. Machine verification was always free, but then there was the option to get basic identity verified for a reasonable price (getting a level 2 cert), then an organization, and then a more extensive organization verification. At each step once you had a given level of verification done you could then get certs without further payment for the validity period, in stark contrast to the artificial expense CAs normally add. In an ideal world cryptographic authentication would be part of the standard services offered by government, and in fact authentication should be a core function of government period, but that is not the case.
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.
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.
This was the final straw on StartSSL for me. :(
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.
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.
Now that LetsEncrypt exists there's no excuse for anyone to use StartCom. They've had a whiff of dodginess for ages, and their customer service is among the rudest I've known. This should be the final straw. Their root needs removing from browsers. Give their existing customers a year's warning.
Their customer service is rude. But they're giving you free certificates, and they have customer service. That's already better than what you get when you pay for Google services or have a Windows license and run into Windows problems or something.
Lesson of the day: public perception of customer support is important. Rude support worse than no support at all. Noted.
Lesson of the day: public perception of customer support is important. Rude support worse than no support at all. Noted.
I've had terrible service when paying them hundreds of dollars. There's no correlation.
Wildcard domains aren't supported by Let's Encrypt last I checked.
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).
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).
> Wildcard domains aren't supported by Let's Encrypt last I checked.
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).
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).
I believe that's exactly the use case of secure Bugzilla attachment hosting the OP mentioned. IIRC, it will generate the subdomain on the fly using ticket ID in the form of bug12345.bugzilla.example.com to host the attachment.
Ah, interesting. Haven't worked with Bugzilla for years, didn't know they added this.
I agree with you, there is no alternative to StartCom right now in wildcard certs. While GNOME got a free account to get those certs, the last time i checked is still the cheapest way to get wildcard certificates (60 usd for unlimited wildcard certs).
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.
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.
I actually asked Eddy Nigg (startcom CTO) to do the gnome deal and give us ssl certs for free (back when I was able to ssh/irc from work and be a member of the GNOME Sysadmin Team), which they did. As much hate as they get, they are one of the few "secure" CAs of all of them I've ever worked with. One of the more quiet things when it was first revealed Comodo was hacked was that Startcom was also hacked. Eddy went on the record as bragging not a single rogue SSL certificate was issued as they have a human validate every single certificate request (yes seriously) and that prevented any rogue certificates.
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.
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.
They definitely don't visually check every cert any more. They're issued instantly.
Oh I wasn't referring to their lame knock off letsencrypt product, but their main ssl cert.
Their normal ones are issued instantly also.
GlobalSign gives free wildcard certificates to open source projects: https://www.globalsign.com/en/company/press/061913-globalsig...
I know I'm in the minority on here, but...
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!
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!
> 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.
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.
> 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.
Believe it or not - Large Financial still roll out BBs, mainly because they have a big investment in the BES backend, and don't want to replace it unless they absolutely HAVE to. Latest version of BES (v12) supports iPhone and Android now, but it's not as complete as native BB support.
My Blackberry is personal though (I love hard keyboards!).
My Blackberry is personal though (I love hard keyboards!).
That's a pickle to be in. Until LetsEncrypt is trusted on BB, you might consider switching to a different traditional CA. For example, Namecheap resells Comodo certs for $9 per year: https://www.namecheap.com/security/ssl-certificates/domain-v... . That's what I was using on my personal domains until LetsEncrypt came around.
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.
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.
Yeah, I guess it's time to stump up cash for a proper cert. I actually need about 5 tho...
I would be very surprised if there was no way to side load root CAs on enterprise deployments of Blackberry.
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.
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.
We have been working on Blackberry 10 support for a while. While we can't commit to a date yet, we have good reason to believe that your issue will be solved with a software update soon.
I manually added their cross-signing cert months ago and trusted them on my BB10 devices. Works fine. Haven't added the new root yet. You'll need to download them manually to the phone then go to Settings > Security and Privacy > Certificates > Import
As an aside, I found this amusing: https://community.letsencrypt.org/t/inclusion-of-isrg-root/9...
As an aside, I found this amusing: https://community.letsencrypt.org/t/inclusion-of-isrg-root/9...
How to disable CAs on firefox (thanks user nmc):
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.
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.
How can laypeople know which certs can currently be trusted? Is there a list of ratings somewhere, or maybe a whitelist of some kind?
I'm working on such a project. The ratings are based on a few well-defined criteria. Stay tuned!
How do I stay tuned? Sounds quite interesting.
Potentially useful to that end: https://git.cryto.net/joepie91/ca-incidents
Be aware that there are known issues with the certificate manager, and some changes may not work as you expect: https://bugzilla.mozilla.org/show_bug.cgi?id=585352
Don't forget to disable them in Android (and iOS?), too.
Remember that editing the root CA store is not possible on Android Nougat anymore, to prevent MitM proxies for adblocking or debugging apps you didn't develop.
It's still possible to remove CA certificates from the trust store on Android Nougat. It's also possible to use custom CAs for apps that explicitly opt into trusting custom CAs.
> not possible on Android Nougat anymore, to prevent MitM proxies for adblocking or debugging apps you didn't develop
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.
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.
Btw, more info: https://news.ycombinator.com/item?id=12061320
You are certainly welcome.
WoSign seems to give away all the signs of malicious CA. Why haven't browser vendors banned them (both) already?
It doesn't seem like browsers are willing to revoke certificates from these dangerous CAs, but what about a compromise that flags some certificates as less trustworthy?--a certificate tier, if you will. I'm envisioning a warning page in the style of Firefox's "This Connection is Untrusted" that would require the user to consent before proceeding to the page. Or removing the lock icon if that's too intrusive. It wouldn't break websites but it would bring attention to websites' choice of security and probably spur action from those affected. The whole system needs an overhaul but we also need a stopgap.
I think this is definitely needed to keep CAs viable, but this requires cross-signing to be much easier. It should also be possible to get signed certificates by many CAs.
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.
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.
Damn, we (sqlitebrowser.org) recently went through the process of obtaining a MS code signing certificate... from StartCom. (so we can sign our release binaries)
sigh
sigh
[deleted]
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.
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.
[1] https://wiki.mozilla.org/CA:IncludedCAs
I think you're right, this blogger is focusing their attention on this CA.
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".
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".
To un-trust on OS X:
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.
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.
131hn(2)
Both should be revoked.