Should we trust CA certificates?

A recent update in python-certify made me think about how this could affect us, and if/how this could be handled differently.

The problem

When checking the validity of the certificate of Github, we rely on Certificate Authorities, and more specifically on the "trusted certificates" bundle shipped with python-certifi. This bundle ships different root CAs, on which we don't have full control.

There are two ways for an attacker to proceed:

An attacker is able to acquire a rogue certificate from a trusted CA in the name of the github.com. This is similar to what has been used by "Intellexa's Jupiter" spyware (see this video at the 37C3 for more info)
An attacker is able to inject a rogue CA into the client’s trust store.

On this second case, because the client could be compromised, there is nothing we could really do, so I propose letting this aside for now.

But, let's consider what could happen if an attacker would gain access to github releases, with regards to dangerzone. It could:

[...] serve an older, vulnerable version of Dangerzone, instead of a new update.

[...] silently drop updates.

[...] know which users download Dangerzone updates.

[...] serve a malicious binary (requires a joint operation from a malicious CA as well, for extra legitimacy).

— updates, security considerations.

Mitigations

The only reason we're hitting github.com is to get the version updates. It seems that there are two ways to solve this, and one only seems very practical:

Pinning ({root,intermediate,leaf} certificate)
Using certificate transparency

Pinning the certificate

One way to circumvent this would be to "pin" the certificate to a known one. This would make sense only if we control the client and server certificates.

On this, OWASP has issued a guide where they advise that for most of the cases, pinning shouldn't be considered:

There is almost no situation where you should consider pinning. The risk of outages almost always outweighs any security risks given advances in security

— OWASP - Pinning Cheat Sheet

In our case, and because we're really using github only to know if there are updates, maybe it is still worth considering.

Certificate transparency

The "goto" way to solve this nowadays (and since the fall of HPKP), seems to be using certificate transparency, at least for browsers (which isn't our case).

To be effective, this would need some of — maybe only the signatures ? — our assets to be hosted on a domain under our control (dangerzone.rocks). This would enable us to know when specifically Dangerzone is impersonated, unfortunately without knowing who is the end target, if this arises.

In any case, monitoring our certificates seems a good step in the right direction (but I wonder if it would be enough).

Signing

Our releases are currently signed, which means the first line of defense is here. Signing, unfortunately, doesn't cut it for scenarii 1, 2, and 3.

Thanks a lot Alexis for the dig. It took me a while to reply here due to some other issues that were affecting Dangerzone, but now I'm here.

So, here's my take on the mitigations:

On "Pinning the certificate", I'd agree with OWASP suggestion. We don't control GitHub's certificate, so older Dangerzone releases may have a problem at some point.
On "Certificate transparency", I wonder if there's a Python requests add-on that can check signed certificate timestamps, as user agents do. I see that Python cryptography has a way to validate CT logs (see here), but not sure how we can integrate it with an HTTPS request.
On "Signing", that seems to me like the path of least resistance, indeed.

However, the elephant in the room here is: what about the Sparkle project? It's more user friendly, offers good enough security guarantees against the attacks you mentioned, and it's used by lots of projects. We never managed to pull it off due to time constraints and complexity though.

re: pinning

I'm also inclined to say it's not worth bothering with. It sounds like a potential annoyance treadmill for y'all, and depending on how often GH changes up their certs and how quick y'all are at noticing and updating the pinsets, it could end up eroding user trust.

re: certificate transparency

I did some digging, and that whole ecosystem really isn't set up for non-mobile application development. I wasn't able to find much of anything that emulated CT user agent actions in python, and CT monitors aren't really advertising ways to programatically query their databases. That said, crt.sh allows you to force a response in json using a URL parameter like so: https://crt.sh/?q=%25.github.com&output=json

So one option is to write something that uses the requests lib to check that CT monitor, get the client to grab a GH SSL cert's Signed Certificate Timestamp, and validate them against one another.

The way the ecosystem is set up, though, is oriented more towards monitoring of CT logs to see if someone is issuing fraudulent certs for your domains and then take it up with the CA responsible. It really favors big orgs that can afford to have dedicated SOC-style operations (i.e. not us). Cloudflare sends alerts to that end if you opt into it: https://developers.cloudflare.com/ssl/edge-certificates/additional-options/certificate-transparency-monitoring/

We do have that feature turned on, so if you wanted to do something like putting signatures on dangerzone.rocks we're already set up for it. In fact, I'd support putting any validatable build-related metadata for the latest release up there as part of y'all's release workflow.

In the interest of transparency, I'll note that I haven't been actively monitoring the alerts. While it's no excuse, Infra is just too overburdened to really do a good job keeping up with all the various sorts of things like this. Still, I will make more of an effort to do so and give y'all a heads up if I notice anything strange.

Thanks a lot Ada for your input. Ok, let's put the pinning option to rest. Now, with regards to CT, thanks for the dig. I wanna focus on the last point you mentioned actually:

We do have that feature turned on, so if you wanted to do something like putting signatures on dangerzone.rocks we're already set up for it. In fact, I'd support putting any validatable build-related metadata for the latest release up there as part of y'all's release workflow.

We had this discussion with Alexis and Erik as well, and I think the consensus was that now that https://dangerzone.rocks is under our control (previously it was hosted on GitHub pages), this is feasible. The fact that we have CT alerts as well is the cherry on the top.

In the interest of transparency, I'll note that I haven't been actively monitoring the alerts. While it's no excuse, Infra is just too overburdened to really do a good job keeping up with all the various sorts of things like this. Still, I will make more of an effort to do so and give y'all a heads up if I notice anything strange.

Thanks Ada :slightly_smiling_face:

freedomofpress / dangerzone