If you recall the scene in Meet the Parents where the characters played by Robert De Niro and Ben Stiller discuss the “circle of trust,” then today’s blog will resonate with understanding of how your own digital circles of trust are constructed.

When two computers exchange encrypted information, both must be inside each other’s circle of trust. The way they do this is by installing a digital certificate that references a common root Certificate Authority (CA) in their applications. Certainly, the most common applications are web-related and in this case, both the servers and the browsers need to trust each other. But there are many other applications that need certificates to enable encrypted operations. The key takeaway here is that just like Stiller’s character, these CAs sometimes wander outside their trust circles.

How this happens is usually the result of human error – either deliberate (as with some hacker trying to force their way in) or a genuine configuration mistake (on the part of some administrator or programmer). This is a very specialized field and not that many people have the skills or the experience to set up CAs.

As a result, over the years there have been some spectacular failures of trust with certain CAs – this blog post documents many of them. For example, back in 2011, an attacker completely compromised DigiNotar and after obtaining full administrative access to all its critical CA systems, issued rogue certificates for numerous domains. That was a massive cleanup effort.

Another one of the more notable situations happened back in 2015, when Symantec sold off its entire CA business to Digicert. Symantec had one of the longest-running and popular CA roots, in use by millions of websites, and sadly, some of these certificates had become untrustworthy. With several years’ worth of effort to try to fix the problem, Mozilla decided in 2018 to make all the certificates issued by Symantec untrustworthy. 

The trust world got another bump in the road recently when Google decided to ban Spanish CA Camerfirma after repeated operational violations. The ban will come into effect with the launch of Chrome version 90, scheduled for release in mid-April.

How to know if you are still trusting Camerfirma’s CA

Or for that matter, what other CAs are you using? There are several ways, depending on what endpoint device and application you are using. The easiest ways to see this list of trusted CA s is by visiting this page, where Apple lists its CAs for its devices, or by running certmgr.msc at the Windows CMD line.  

You can also bring up your browser’s advanced security settings, and it will show you something like this screen below. This shows just a portion of the trusted root CAs that my browser has cataloged. It is a long list.

These certificates are used to decrypt HTTPS traffic. After the ban takes place, if a website is using the Camerfirma CA, its pages won’t load and you’ll see an error. This was not some capricious move on the part of browser providers. The company was given numerous warnings to clean up its act, in fact more than 25 such warnings over several years.  

One of the reasons for the popularity of these CAs is thanks to a free open source effort called Let’s Encrypt that has received support from numerous foundations, including Avast. Several years ago, computer security developers got together behind this effort to try to popularize HTTPS across the internet. They were widely successful in distributing their free certificates. (Widely, because criminals got on board to try to disguise their malicious websites by hiding behind this protocol.) 

The problem is that not every security tool can decrypt and correctly identify this traffic. For example, the operations of the Zeus botnet was hidden behind encrypted websites. More ransomware attacks are delivered with encrypted web traffic.