This is bad: the UAE's favorite sleazeball cybermercenaries have applied for permission to break Mozilla's web encryption

#1

Originally published at: https://boingboing.net/2019/02/22/my-voice-is-my-passport-2.html

5 Likes
#2

@doctorow Thank you! Is there a way Firefox users can disable trust of Darkmatter’s specific certificate? And does an organization like EFF by any chance maintain a whitelist and or blacklist of certs recommended to trust/not trust?

8 Likes
#3

I suspect another browser plugin from the EFF, alongside the excellent Privacy Badger and essential HTTPS Everywhere, may be in order.

8 Likes
#4

Slightly ironic here. :smirk:

3 Likes
#5

But who are we to say if they are good or bad? Have they been convicted in a court of law? Was it the Supreme Court? No? Then I guess we just have to shrug our shoulders…

#6

still a VERY BAD IDEA, and not to take away from that, but certificate pinning thwarts much of this SSL fuckery.

https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning

1 Like
#7

“Options” -> “Privacy & Security” -> “View Certificates” brings you to certificate manager which allows distrust or deletion of bundled root certs(along with a variety of other operations on certificates, it’s the complexity that makes being a default extra powerful).

As for a list of who to trust, I’m in less of a position to be helpful. The moral of the story uncovered by fine folks like the SSL Observatory is that there’s quite a thicket of direct and indirectly trusted stuff treated as ‘default’; and also the problem that what you really want to be concerned about is unexpected changes in CAs cropping up, which means you need historical data in addition to any basic trustworthiness metrics.

Someone like, say, DigiNotar wasn’t overtly sleazy prior to the big incident, and even then it was more an issue of arrogant incompetence rather than being a nerd merc; but during the period where unknown interested parties were merrily minting certs with them you would really, really have wanted to know if a site you were visiting had mysteriously changed registrars overnight; or had a different registrar on specific ISPs.

That sort of historical data is considerably more challenging at any scale. Pinning is the closest reasonably practical approach to it; but scales poorly, which is why you only see it on occasion.

5 Likes
#8

You just gotta love the evil companies sticking with evil sounding names.

Dark Matter? Aren’t they something to do with kindness and puppies?”

3 Likes
#9

Y’know how there’s the 99% and the 1%?
Well Dark Matter is the… 27%:

https://science.nasa.gov/astrophysics/focus-areas/what-is-dark-energy

3 Likes
#10

Oh, really?
Say, I have some Spanish land grants that has been in my family for generations. I can let you have them for, say, $1 million each.
I also have FL land in the Everglades & the title to a bridge in Brooklyn.

2 Likes
#11

What is the consequence if restricting trusted certs to a very few trusted actors? (And thank you.)

#12

That’s a long read, can you tease a very short overview of the substance to entice my attention organs that way?

1 Like
#13

Typo. The company name was supposed to be Dankmatter.

2 Likes
#14

I really like this explanation of cert pinning a Mozilla employee wrote a while back:

Pinning allows site operators to specify which certificate authorities (CAs) issue valid certificates for them, rather than accepting any one of the hundreds of built-in root certificates that ship with Firefox.

So basically, Google (or any other site) can say “only trust these artisinal, hand crafted loving certificates” rather than offloading that decision to the browser.

2 Likes
#15

As long as your trusted roots(or specific trusted certs if you have a few self-signed around that need to be accommodated) cover the sites you care about; no consequence. That would theoretically be an ideal configuration.

Unfortunately, there’s no especially good way to know exactly what that list of trusted roots ought to be; both because sites do sometimes legitimately change CAs for one reason or another and because sites that incorporate assets from multiple domains(which, thanks to advertising and commonly reused JS libraries and such, is by far the rule rather than the exception) are reliant on those domains also being trusted properly or you’ll get the mixed mode situation.

By way of example I pulled up the certificate hierarchy for bbs


then removed DST Root CA X3 and retested:

That’s what you’d expect to see(sites that don’t specify HTTP strict transport security would allow you to choose the “I’d like to make a terrible decision and add an exception in this case” option to bypass the error; here you can’t because they do) for a site that is presenting a certificate that doesn’t derive from one of your trusted roots. Exactly what you want if someone is trying to MiTM you using a cert from a dodgy CA, deeply unhelpful if you are just seeing it because you’ve distrusted a CA that about a zillion websites legitimately use(as was the case here, by distrusting the DST Root CA X3 I was effectively breaking things for any site using Let’s Encrypt; which is probably not what you want).

There are very likely roots you can distrust without consequence (I’m certainly not sure that I’ve ever knowingly interacted with one of "Guangdong Certificate Authority"s customers); and you can always experiment; but the real problem is knowing who is actually using what; and keeping track of any dodgy intermediate certs. On those issues I can’t really provide much useful advice I’m afraid.

1 Like
#16

certificate pinning tl;dr:

  1. remember public key received for a given site
  2. pin the browser to it
  3. raise holy hell if it changes

this is similar in concept to the way that ssh determines trust. intentionally glossing over stuff about http headers, certificate expiration, and probably other details. it’s actually a lot more complicated, the current implementation (known as HPKP) has some flaws, and has being deprecated by Google in Chromium.

Ivan Ristic wrote a series of articles about the issues and possible solutions:
https://blog.qualys.com/ssllabs/2016/09/06/is-http-public-key-pinning-dead

#17

You can use Preferences/Privacy/View Certificates to edit the list of top-level Root CAs you will trust or distrust in Firefox. Unfortunately, the certificate in question is a Subordinate CA certificate, which is already implicitly trusted because it was signed by QuoVadis’ root CA cert.

What you might be able to do is import the certificate in question as a trusted certificate, then click the button to “Delete or distrust” and flag it as bad. However, I’m not sure if Firefox will let you import and trust an SCA (non-root) certificate. And if you can, I’m also not sure if there is an option to Distrust-without-deleting, without which the whole exercise would be pointless.

Note that you probably don’t want to distrust the parent Quo Vadis root certificates. They are the basis of trust for a lot of web sites. If you distrusted their root, much of the web would go dark for you.

That said, by signing these bastards’ issuing certificate, Quo Vadis has already climbed in bed with the devil. Maybe this needs to become a teachable moment for all CAs.

To answer your other question, yes, there is such an organization. The are called the CA/Browser Forum, and they vet certificate authorities to make sure they uphold standards of trustworthiness and security. They should be adamantly opposed to including a spy organization in their list. If they would, they’re of zero value to the world.

1 Like
closed #18

This topic was automatically closed after 5 days. New replies are no longer allowed.