“We manage certificates so you don’t have to” is something I frequently say to customers.
There are days where our automated systems renew thousands of certificates for their associated Atsigns, and those systems generate reports on renewals, failures and forecasts.
It’s been a busy week in security, with the eMudhra Intermediate CA Compromise landing in amongst PHP2Shell, the PingCAP/TiDB breach, and a critical GitLab Remote Code Execution advisory. But thankfully only the first affected us at Atsign as we don’t use PHP. TiDB or GitLab. One issue can lead to lots of work though. US universities are scrambling to replace thousands of certificates issued by Internet2 following eMudhra’s EEC root being pulled from trust stores. Users of eMudhra certificates are just the tip of the iceberg, as everybody else rushes to ensure that their systems aren’t susceptible to man-in-the-middle (MITM) attacks.
That has touched Atsign a little, as there were a couple of Dependabot tickets to bump the Python certifi library in lockfiles where we use Python. But we’ve not had to rebuild or redeploy any core infrastructure, because we never trusted eMudhra in the first place.
Due to changes in how public certificate authorities (CAs) such as LetsEncrypt work (pushed upon them by changes to Chrome’s policy) we had to re-engineer our approach to mutual Transport Layer Security (mTLS), which is used when Atsigns talk to each other. As part of those changes we decided to reduce our roots of trust to just the CAs we use: Google, LetsEncrypt, ZeroSSL and our own internal CA. Four CAs, nine root certificates. No CAs that nobody’s ever heard of. No oppressive regime telcos. No eMudhra.
That proactive step to finely tailor our trust boundary meant that there was no eMudhra fire drill over the past few days. No need to patch. No need to rush changes into production. No need for security advisories to customers.
A question I hear from customers a lot is “How do we know that Atsign is secure?”, and my answer is to point to our trifecta of evidence: software bill of materials (SBOMs) to show that we’re not using vulnerable dependencies, Supply-chain Levels for Software Artifacts (SLSA) attestations to show that things are built securely, and Open Source Security Foundation (OpenSSF) Scorecards to show holistic security practices. Those are all evidence of our commitment to security by design, and the tight trust boundary defined by the Atsign cacerts file is another piece of that.
