Comment by dannyw
3 hours ago
I really don't understand your justification.
One of the certificates literally has a private key of 4; it's as compromised as it could quite possibly be. This is not a "one of the intermediates have a weak and possibly crackable key" or "a bunch of incorrect certs were issued but the issuance was patched".
To a MITM attacker, git clones can be easily distinguished from visiting in Safari. You could choose to only poison git clones; without poisoning anything else.
Heck, you can probably build an exploit kit in a hour; camp out around a Starbucks or McDonalds with open wifi, and start compromising git clones and deliver malicious payloads.
An attacker absolutely cannot “easily distinguish” between a git clone and visiting the website and swap the certificate.
To know whether a request is a git client or web browser, an attacker needs to be able to inspect the contents of the web request (to check the user agent or whatever). If the site is using a legitimate certificate, the attacker has no way to inspect the contents because it is encrypted with a key they do not control.
If an attacker used their own, eMudhra-signed certificate, it would throw the certificate error in Safari.
Yes, I'm assuming network MITM and DPI.
The whole point of TLS and certificates is to counter network MITM attacks.
Browsers and clients emit a lot of fingerprints, you can probably figure it out loosely from the TLS initialisation.
So let’s take a step back and look at this threat model.
1) An attacker is MITMing your connection. This is already not easily exploitable by most threat actors short of being on a public Wi-Fi network, otherwise you are likely at the nation-state level attacker at this point.
2) An attacker knows exactly which Git repo you’re about to clone and has prepared a malicious version (noting they can’t snoop on your encrypted web traffic).
3) An attacker has developed a way to differentiate between Git over HTTPS and Safari, by using a side channel “fingerprinting” method that works with your exact versions of git and macOS.
4) You don’t pin the git clone to a particular hash or signature.
This is already a very low level of exploitability. All of these things need to be satisfied for the attack you’re describing to work.
Now let’s look at a more practical attack that exists regardless of if you have the patch from Apple.
1) A maintainer of an open source project you use has their GitHub account compromised due to credential stuffing and commits a malicious version.
2) You don’t pin the git clone to a particular hash or signature.
This attack is significantly more exploitable and has happened over and over again in supply chain attacks.
But look at the commonality: in both, no certificate pinning or signature checking was done. If you follow best practices, this stops both attacks dead cold.
This is the security engineering. It’s not just checking boxes. It’s evaluating risks.
1 reply →