SoylentNews is people
SoylentNews
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: 5, Interesting) by pTamok on Tuesday February 26 2019, @11:32AM (4 children)
I have never understood why it is not easier to edit the list of trusted root certificates* - personally, I would like to start with an empty list, and add CA roots whenever the browser finds a new one by popping up a dialogue that says something like: New root certificate entry needed - Allow permanently, allow once, deny permanently, deny once?:
This would allow me to research the CAs I'm trusting before using them, and by default deny any new ones.
As it is, a large number of organisations I've never heard of ( see Mozilla's list here: https://wiki.mozilla.org/CA/Included_Certificates [mozilla.org] ) say that I should trust that data communicated with a site using one of their certificates is secure against third party eavesdropping whilst in transit.
Since I'm not planning to transact business with sites secured by, say, Chunghwa Telecom, E-Tugra, or , I would be nice to be able to flag up when I'm unexpectedly relying on them.
*Mozilla bug is here: https://bugzilla.mozilla.org/show_bug.cgi?id=545498 [mozilla.org] "Provide Capabilities to Detect and Manage Root Certificate Inconsistencies", Staus is "RESOLVED, WONTFIX". You can use the CLI utility 'certutil' to list non-default Root Certificate settings: https://superuser.com/questions/734208/is-there-a-program-to-check-the-list-of-root-cas-in-firefox [superuser.com] - it is not exactly a 'user friendly' process.
(Score: 3, Insightful) by zocalo on Tuesday February 26 2019, @11:53AM (2 children)
UNIX? They're not even circumcised! Savages!
(Score: 3, Interesting) by hoeferbe on Tuesday February 26 2019, @01:31PM (1 child)
This. Long ago, I tried deleting all my CAs, intending to only accept server certificates that I verified through a secondary route. Not only was it a tremendous hassle since various huge entities would have different certificates that expired at different times for their ephemeral cloud / content delivery network machines, but yes, a Firefox update undid all that work.
I tried using Certificate Patrol [psyced.org] for much the same reason. Yet, even with its ability to whitelist by domain names, it was still too much of a pain caused by clustered sites using several inconsistent certificates.
(Score: 3, Interesting) by pTamok on Tuesday February 26 2019, @06:37PM
I used to use the Firefox Extension 'Perspectives' from CMU, but it ran into the sand. It was a nice idea - there is still a zombie website [perspectives-project.org], but little else to show for it.
It checked to see if the certificate* you got for a website was the same as other users got by using public notaries that kept track of certificates from multiple different locations. A MITM attack using a certificate that passed browser validations substituting for the actual certificate would be detected, as checking the public notary servers would show the discrepancy.
More details here: Perspectives: Improving SSH-style Host Authentication with Multi-Path Probing Dan Wendlandt, David G. Andersen, Adrian Perrig Carnegie Mellon University [cmu.edu] (pdf)
It is something that I wish had been taken further.
*Actually, server public keys.
(Score: 0) by Anonymous Coward on Tuesday February 26 2019, @06:54PM
In a sane CA system, sites would have certs signed by as many CAs as possible. If one CA shows the slightest sign of misbehavior, users blacklist them -- and it doesn't break the interwebs, because everybody worth a damn uses multiple CAs. This threat of immediate blacklisting, in turn, gives CAs some motivation to do their fucking jobs, to do them right, and to be seen to be doing them right. And it doesn't rely on all users having the same list of trusted CAs -- if you have 3 or 4 of the top 5 CAs, that's going to give you pretty much complete coverage.
But our system is broken by design -- each site must choose only one CA. So blacklisting any CA instantly breaks every site that uses that CA, with no fallback. The inevitable result has been that browsers maintain a uniform list of CAs that are trusted, users are discouraged from changing this list, and that even once we have clear proof of a CA's untrustworthiness, there's much delay and hand-wringing before the major browsers will actually remove them from the list.
It's also broken in another way, though at least there's been some effort to fix this one. Given one CA per site, you might expect some hierarchy or per-site definition defining which CA a given site could use. Otherwise, when one CA is compromised, they could sign certs to MITM any site in the world, not just the ones that use them. But no, every CA you trust at all is trusted globally. You can't say "I trust CA X for sites A, B, C, and D, and CA Y for sites E and F" -- even though site A has always used CA X, and seeing a cert for that site from CA Y would suggest something fishy, your only choices are to not trust CA Y at all (thus breaking sites E and F) or trust it globally. There's multiple efforts to deal with this (DANE, HPKP, etc.), but none are universally adopted yet.