[xyzzy123]

Given that there seems to be no security impact (and none expected in the next year or two)...

Curious why everyone doesn’t agree to use 64 bits in future and just let the mis-issued certs live out their natural life?

Seems to create a lot of busywork for lots of people for no discernible benefit?

[Buge]

The reason for the urgent fixes is to promote uniformly applied rules. There are certain predefined rules that CAs need to follow, regardless of whether the individual rules help security or not. The rules say the certs that are badly formed need to be reissued in 5 days.

If these rules are not followed and no penalties are applied, then later on when other CAs make more serious mistakes they'll point to this and say "Apple and Google got to disobey the rules, so we should as well, otherwise it's favoritism to Apple and Google."

[mmastrac]

No idea and completely unsourced, but one of the site comments states this:

> 4) This only came up because of DarkMatter, a very shady operator who most people are very happy to have an excuse to screw with technicalities.

Edit maybe these are sources?

https://bugzilla.mozilla.org/show_bug.cgi?id=1531800

https://groups.google.com/forum/#!msg/mozilla.dev.security.p...

Still not getting the whole picture.

[geofft]

The basic story as I understand it is that DarkMatter under contract to the United Arab Emirates wants to become a trusted CA, and they are widely expected to start running a governmental MITM once trusted, but the CA root programs don't have any provision for "You're a bunch of sketchy creeps, we don't trust you." (Oddly enough for a "trusted" root program, there is generally no actual evaluation of trust as conventionally defined. The "trust" part is "can you pass audits and generally be technically and organizationally competent to not let your private key be stolen / your infrastructure be abused by an attacker." Individual employees are part of the threat model, so there's usually a two-person rule for access to the private key; entire malicious organizations willing to lie in public and cover their tracks are not envisioned by the model.) So people are trying to block their application by nitpicking technical mistakes that, by the letter of the Baseline Requirements, disqualify you from being a CA.

https://www.eff.org/deeplinks/2019/02/cyber-mercenary-groups... covers some background on DarkMatter.

One of the Baseline Requirements is you may not issue certs with fewer than 64 bits of entropy. Turns out DarkMatter was doing that, by issuing certs with 63 bits of entropy. Also turns out this was a thing lots of CAs did. Now that it's been pointed out publicly....

[pryce]

It's amazing that we anticipate having to revoke malicious CAs as a crucial part of a security model, yet we have basically no plan to ensure that we don't accept a competent-but-malicious CA into the fold in the first place.

[callalex]

Competency in this case can be objectively reinforced, but maliciousness requires one to device who is “bad” and who is “good” which is not a technical problem.

[Ajedi32]

That's a bit misleading I think. There's no evidence whatsoever that DarkMatter plans to abuse their CA to MITM users. DarkMatter has been in possession of a trusted intermediary certificate for years now, so _if_ that was something they wanted to do they could have done it a long time ago.

The reason people are concerned about DarkMatter is that they have (allegedly, they seem to be denying this) previously developed and sold software that can be used to MITM connections (though not by abusing any CA certificates), and that this software has been used for less-than-noble purposes.

So yes "You're a bunch of sketchy creeps, we don't trust you." is an accurate assessment of some people's opinions towards DarkMatter, but "widely expected to start running a governmental MITM once trusted" is inaccurate.

[lixtra]

The whole CA system is fundamentally broken.

When you point a virgin browser to a new ssl endpoint the user should be presented with the certificate and a list of certificate chains that imply trust in the certificate. At that point you should decide which certificate to trust or not. This can be

- only the end certificate (because you verified the hash),

- some intermediate certificate or

- some/all root certificates (that come with the browser).

Obviously the last option is stating “I’m incompetent and/or blindly trust the browser”. Unfortunately it is the default and the software doesn’t help you to manage certificates you trust in a reasonable way.

For me it would be okay to turn of dumb mode during installation. As a start, the green address bar could be used for these user trusted certificates (instead of for EV).

[geofft]

Not obvious to me at all. I would say that believing you can manually verify hashes in a trustworthy way is incompetent. Where do you get the hashes to compare against from?

[lixtra]

You get the hashes you trust from the counterparty that you trust. I.e. your bank could print it everywhere.

It’s not less obvious than just trusting your browser vendor.

EDIT: Also note that in the presented approach you can still trust some root CAs. It’s just that the user has to do it explicitly.

[isostatic]

I’d like to be able to limit certain privately imported root certificates to specific domains — that would be a valuable feature in a browser to protect against corporate hijacking.

However for the average person what you propose is meaningless.

[im3w1l]

I know nothing about DarkMatter so this may nor may not be justified but I just want to make the point that they could be kicked out if they actually did make MITM certs. There are certificate comparison programs that try to spot them.

[geofft]

In theory, yes. In practice, letting them in and then kicking them out still lets them do damage: certificate revocation doesn't work in the presence of MITMs (and in the absence of MITMs, you don't really need certificates...) as described at https://www.imperialviolet.org/2011/03/18/revocation.html , so allowing the CA into the program allows them to keep conducting attacks even if revoked. There are browser-specific revocation-like things like Firefox's OneCRL and Chrome's CRLSets (and there's always straight-up browser updates), but from a network perspective, they're as blockable as actual revocation sets. So if the threat model is a nationwide MITM by the government, it won't help you.

You also need the recipient of the MITM cert to notice it and report it. It's generally hard to MITM an entire nation's traffic, for reasons of computational overhead. So instead you let people browse the web normally, and you deploy MITMs against specific targets for specific sites for limited times. It's probably easy for the MITM to do this in a way that avoids the victim noticing that the cert is illegitimate, and also probably easy for the MITM to prevent tools that report suspicious certificates from sending that report to the internet at large.

(Also, if your threat model is a malicious lying CA, things get much harder under the current practices: a CA has actually said "Oh, that was an internal test certificate for google.com, it didn't actually go anywhere, but also we've fired the employees who thought issuing a test cert for google.com from the prod CA was a good idea" and not been revoked. So if you get caught, just say something like that and don't fire anyone, and there's a nonzero chance you won't get kicked out.)

[isostatic]

Once kicked out (due to certificate transparency or due to finding out ala diginotar) the next browser update will remove them, and the CT people won’t deal with them.

Doesn't Chrome now require CT?

Not great, but doesn’t rely on crls or other broken systems.

> It's generally hard to MITM an entire nation's traffic, for reasons of computational overhead

Isn't that what Iran did with DigiNotar?

[ethbro]

Are there any that cover the one-in-a-million targeted MitM scenario?

My understanding of current cert transparency efforts was that they wouldn't catch "we fingerprinted your connection, identified you, and are just injecting a malicious cert for you" scenarios.

And were more targeted at the "rouge / misconfigured CA signing half the internet" to any client mishap.

[geofft]

Mandatory CT does actually solve that: if a browser won't trust a cert without seeing it include a signed certificate timestamp from a trusted log, then the CA has to disclose certs, even if they're only targeting one user.

But most people don't have e.g. Expect-CT set up, so it's not clear it would help on a majority of sites.

(One reasonable option would be to require certs from DarkMatter, and really every CA going forward, to have SCTs in their certs, and enforce that with a flag in the root store. But if there's a concern about DarkMatter specifically, it's probably better to phrase a change to the root store policies that say "We won't accept CAs we just don't trust" instead of waiting for them to misbehave and then rescinding their membership.)

[isostatic]

> it's probably better to phrase a change to the root store policies that say "We won't accept CAs we just don't trust" instead of waiting for them to misbehave and then rescinding their membership

Unless you can define the policies up front that's a very risky road to go down. Why refuse to trust DarkMatter, but not refuse to trust China Bank?