Leaked SSL Intermediate Certificates: https connections cannot be trusted

[u/moanos]

curl https://q3k.google.com --resolve 'q3k.google.com:443:135.181.235.221'
<!DOCTYPE html>

<meta charset="utf-8">
<title>q3k.google.com</title>

<meta name="viewport" content="width=device-width, initial-scale=1" />
<link rel="shortcut icon" type="image/png" href="/favicon.png">

<style>
body {
font: courier, sans-serif;
font-size: 12px;
text-align: center;
margin-top: 100px;
}
</style>
<p>

<b>oh, this is bad</b>
</p>

Yeah, eight SSL Intermediate Certificates of eMudhra have been publicly leaked. All your servers https traffic can be broken right now. Browsers are fine as they have revoked the certificates but as you can see, curl and many other libraries still accept those.

No download can be trusted right now. Remember to not only patch your main systems but every docker container you run.

This is bad 😅

[u/AtlanticPortal]

If a binary has certificates inside that are not under your control (certificate pinning) then you have a big, big problem.

[u/throwaway490215 → u/AtlanticPortal]

Its not great, but what exactly is the attack vector?

Afaict, the vast majority of users are under threat from an active MITM attack when only the DNS name is being used.

When a binary/app on a client/user has a pinned cert to connect to your server, then i'm assuming we mean its pinning the full certificate, which names your public key.

The parent/intermediary cert being compromised effects nothing in that case. A MiTM wont work.

[u/struggling-sturgeon → u/throwaway490215]

Doesn’t it mean the threat actors can now generate certs? So they can just create a cert for your domain name and it’s going to be trusted and they can then use that for the MITM. I could be totally wrong.

[u/throwaway490215 → u/struggling-sturgeon]

Thats the threat for when you're using a browser and enter in the name and somebody is sitting between you and your bank (or VPN or whatever) and is a genuine big problem. All modern browsers have been auto updated to prevent this.

The parent comment is talking about having a cert pinned in an app.

The common reason i know for App developers to do this, is so that an android "hacker" can't easily create and trust their own fake root cert authority, and then MiTM the app to intercept messages.

Or the other reason is to avoid having to deal with the OS native cert handler. Which right about now seems like a good idea because any org who is using the OS cert handler and got their cert signed by the compromised certs, will now be unavailable until they update.

[u/spin81 → u/throwaway490215]

The common reason i know for App developers to do this, is so that an android "hacker" can't easily create and trust their own fake root cert authority, and then MiTM the app to intercept messages.

Wouldn't they have to root their device to do this?

[u/throwaway490215 → u/spin81]

Yes the "hacker" needs to root their device, so its always been a bit of a questionable security choice - but it was additional hurdle to discourage others releasing an unauthorized 3rd party interface/app to your servers.

As the "hacker" you do it because its easier to analyze network trafic than to inspect code.

AI decomp has pushed the 'cost to analyze the binary' so low that its now basically moot, and i suspect cert pinning will become a novelty again.