This week has been a very weird week. A few days ago, eMudhra's private key was leaked. It's private key was revealed to be the value 4; yes, the actual integer four. With this knowledge, it would be fully possible for someone to sign a valid SSL certificate and make it appear valid to the gigantic trust chain system, meaning anyone who employs an eMudhra certificate would fully believe a forged certificate.
This is a pretty large issue for the internet due to how certificate authorities work. Each one consigns trust to one another, meaning that if one authority trusts the other, then a certificate signed under one CA would be trusted by the other due to the math of elliptic curves. However, this only holds if private keys are never known, which eMudhra's key is now widely available.
So in short, it's pretty bad. But also may have funny implications elsewhere, but I'll theorize about that later.
Updating Guix
Upon breaking news of eMudhra going sour, I waited until Guix had a commit land to purge the CA from nss-certs. As of 2143f3c7cd, the NSS certificate package was updated to purge eMudrha's CA entirely.
Ideally at the end of it all, a curl call should look something like this:
$ curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl: (60) SSL certificate verification failed: certificate signer not trusted. (CAfile: /run/current-system/profile/etc/ssl/certs/ca-certificates.crt CRLfile: none)
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.
Guix works in a few steps, but the best place to start is by doing guix pull. If you define your operating system with a system configuration and a home profile, and perhaps servers with deploy, the logical execution would look something like this:
guix pull
sudo guix system reconfigure file.scm
guix home reconfigure home.scm
guix deploy servers.scm
This is going to be a long update since a lot of people are downloading similar updates to get ahead of any future attack vectors. It took me a few hours to pull all the commits and files in to update my system and all my servers as well.
At the end of it, after a reboot, I can no longer curl an eMudhra-signed website. Hooray!
Podman / Docker
Now for problem number two: these CA trusts were absorbed into containers when the containers were built from images. If you did a docker-compose up or podman run at any point prior to this week, you are most likely not safe. The images will reference the operating system's store at build time, meaning the images are frozen with the CA trusts, and will not reflect any changes without being completely rebuilt.
But, this isn't so bad right? Containers are meant to be immutable and stateless, with the state being stored on the filesystem that gets mounted into the containers. If you run your containers correctly, then your software versions should all be pinned to a frozen version, you take everything down, delete all the containers and images, and simply pull it all down as you do your container plays. Not too bad, right?
My use-case is that my Pi-hole lives in my pod stack, and for me to do this would mean I would have to go into my router and disable my IPV4 DNS setting. Sucks, but it is what it is, otherwise once you tear down everything, you will no longer be able to query for the image server. Woops! Don't make it a habit to do this very often, but this is a pretty emergency scenario after all.
My Podman steps went as follows:
podman kube play --down pods.yaml # take everything down
podman rmi -a --force # wipe container images
podman kube play pods.yaml # play all the pods
Docker is a little similar.
docker-compose down
docker container prune
docker image prune -a
docker-compose up -d
If you now run something like this:
$ podman exec -it <container-id> curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl: (60) SSL certificate verification failed: certificate signer not trusted. (CAfile: /run/current-system/profile/etc/ssl/certs/ca-certificates.crt CRLfile: none)
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.
The container should have curl to use as a test, but point being if you remove the CA from your operating system, then the containers should be good once you re-pull everything in.
Conclusions
Update your CA stores, please! Not every application in the world will calculate trust correctly. Upgrade your browsers, upgrade your operating systems soon, and follow any advisories for programming languages specifically. For example, Python's pip package manager maintains its own CA store separately, meaning pip needs to get updated to 26.2.2!