Submitted via IRC for chromas
Surveillance firm asks Mozilla to be included in Firefox's certificate whitelist
[...] The vendor is named DarkMatter, a cyber-security firm based in the United Arab Emirates that has been known to sell surveillance and hacking services to oppressive regimes in the Middle East
[...] On one side Mozilla is pressured by organizations like the Electronic Frontier Foundation, Amnesty International, and The Intercept to decline DarkMatter's request, while on the other side DarkMatter claims it never abused its TLS certificate issuance powers for anything bad, hence there's no reason to treat it any differently from other CAs that have applied in the past.
Fears and paranoia are high because Mozilla's list of trusted root certificates is also used by some Linux distros. Many fear that once approved on Mozilla's certificate store list, DarkMatter may be able to issue TLS certificates that will be able to intercept internet traffic without triggering any errors on some Linux systems, usually deployed in data centers and at cloud service providers.
In Google Groups and Bugzilla discussions on its request, DarkMatter has denied any wrongdoing or any intention to do so.
The company has already been granted the ability to issue TLS certificates via an intermediary, a company called QuoVadis, now owned by DigiCert.
Also at Electronic Frontier Foundation
(Score: 4, Interesting) by bradley13 on Tuesday February 26 2019, @11:53AM (6 children)
There's an easy solution that should have been implemented years ago: Tie CA privileges to specific domains or subdomains. The only organization that should be able to issue a root-level certificate is the owner of that root-level domain, unless some CA can make an excellent case for an exception (and received the approval of the TLD owner).
So, sure, these guys can be a CA. And they can issue certificates for any domain where they can both (a) make a case that they should, *and* (b) get the approval of the owner.
Everyone is somebody else's weirdo.
(Score: 3, Interesting) by iamjacksusername on Tuesday February 26 2019, @01:10PM (1 child)
From a technical standpoint, I absolutely agree. From a practical standpoint, it will never be implemented. The amount of domains with misconfigured spf and non-existent dkim records is staggering and email is something end users actual care about. From the support side, this will result in an endless stream of the same ticket: my browser doesn't work anymore.
(Score: 3, Informative) by zocalo on Tuesday February 26 2019, @02:51PM
A nice idea in a way since root CAs are meant (in theory at least) to be partly responsible for downstream CAs using their certs, and it might also encourage more TLD operators to run a cleaner ship (there's probably no helping some of the "random word" gTLD cesspits out there though), but potentially hugely anti-consumer as it's likely to see prices for certificates on some domains spike considerably with the removal of competition.
UNIX? They're not even circumcised! Savages!
(Score: 2, Insightful) by Anonymous Coward on Tuesday February 26 2019, @01:48PM
Is the SSLiverse a safe place? [media.ccc.de](video) Hint: No.
And that was 8 years ago. Now is not better. Nuff said
(Score: 0) by Anonymous Coward on Tuesday February 26 2019, @10:12PM (2 children)
There exists a standard which can be implemented by the domain owners themselves to restrict which CA's have the ability to sign certificates for their domains. This standard is called Certificate Authority Authorization (CAA). https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-cabrowser-forum [qualys.com]
(Score: 0) by Anonymous Coward on Tuesday February 26 2019, @11:06PM (1 child)
That "solution" depends on the assumption that the real problem is blameless CAs being tricked into signing bad certs. If a corrupt or incompetent CA wants to ignore CAA, there's nothing to prevent them or flag that cert as invalid.
(Score: 0) by Anonymous Coward on Tuesday February 26 2019, @11:18PM
True. It would be nice if the browser itself could enforce this behavior.