Blog

The integrity of a browser's trusted certificate cache is fundamental for identifying MiTM attacks that would otherwise allow virtually any website's identity to be falsely verified.  Which leads us to today's burning question: "How secure is a browser's trusted CA cache?"

Our experts break down the answer:

Firstly, What is a Browser CA Cache?

Every Internet browser has a cache that contains digital certificates for trusted Certificate Authorities (CAs). The browser's cache of trusted root certificates is known by several names such as the "trusted CA cache", "trusted root certificate store" or just "trusted certificate cache". These built-in trusted certificates are used to verify the authenticity of the SSL/TLS certificates provided by a website when a user connects to it. By now we all know that the browser's URL bar will display a warning indicator, typically a broken lock when the browser detects an integrity failure in a website's certificate.

In addition to root certificates, the trusted certificate cache also contains intermediate certificates, which are issued by the highest level CAs to their partner organizations allowing them to also issue valid domain-specific SSL/TLS certificates. These intermediate certificates build a "chain of trust" from the root certificate to the SSL/TLS certificate presented by the website when an HTTPS connection is initiated. Trusted root certificates and intermediary certificates are fundamental for verifying that the certificate issued by a website has been signed by a trusted CA and has not been tampered with or revoked. 

If the website issues a trustworthy certificate, the browser establishes a secure connection with the server. Otherwise, the browser will display a warning message to the user indicating that the certificate is not trusted and the content in the browser window may not be from the actual website indicated by the URL in the browser's address bar.

Without verifying that a website's certificate is signed by a trusted CA, we would not know if the certificate belongs to the actual domain owner or if we were connecting to a rouge attacker-controlled spoofed website. This would allow any attacker with a man-in-the-middle (MiTM) position (the ability to interfere with the connection between our computer and the website) to offer any arbitrary certificate to our Internet browser and we would not be able to verify if it was legitimate.

So, to summarize, browsers come preinstalled with a list of certificates from "trusted entities" who can use their root certificates to sign SSL/TLS certificates that validate the authenticity of a domain you visit on the internet.

Exploiting A Browser's Trusted CA Cache

Unfortunately, the reality is, there are some serious security flaws with this rather simple method of verifying a website's authenticity. What could go wrong here? Plenty. A host of attacks can effectively trick a browser into falsely verifying a website's authenticity, tricking an end-user into thinking the site they have connected to is the right one, while it is actually a site controlled by the attacker. In these cases, the user's browser will not show any indication of comprise but will display that the website is secure.

It's important to note here that in these scenarios, the attacker must not only trick the user's browser into verifying a false certificate but must also have a MiTM position allowing them to intercept traffic between the victim and the internet. However, these attacks are fairly simple, but very powerful and can be used to steal user credentials to virtually any website they try to visit or provide malware-infected files to a user who thinks they are visiting a trusted site.

Let's take a look at several attack scenarios that involve the browser's trusted certificate cache:

Installing Rouge Certificates

Installing rogue certificates can poison a browser's trusted certificate cache by simply adding a malicious root certificate to the browser's cache. To do this, an attacker must have physical or remote control of the target system, or use social engineering techniques to trick the victim into installing a rogue certificate. Once the attacker has added their own certificate to the browser's trusted CA cache, the browser will trust the rogue certificate and establish a connection with the attacker's server while claiming that the website's identity is authentic. Combined with another simple attack such as DNS cache poisoning, an attacker can impersonate any website on the internet opening up a very wide scope of attacks and increasing risk.

In fact, trusted certificate caches can be poisoned by anyone who has physical access to your computer including the manufacturer. In 2015, Lenovo computers were found to have pre-installed spyware from a company named SuperFish that injected its own self-signed certificate into the Windows trusted CA cache and Dell computers followed suit with a similarly poisoned trusted certificate cache. 

Stolen Root Or Intermediate Certificates

Certificate Authorities are pillar organizations that billions of global Internet users and organizations depend upon for their security. To protect the Internet, CAs are audited and held to strict security standards such as the WebTrust for Certificate Authorities standard by browser developers and audited by other organizations such as the government bodies of nation-states. To mitigate the potential of CAs having their certificates stolen they must comply with industry standards and regulations to ensure that their processes and procedures meet minimum security requirements.

However, if root or intermediary certificates are mishandled or stolen from a Certificate Authority (CA), the possessor can issue their own rouge SSL/TLS certificates for any website they wish. These fraudulent certificates can be used to impersonate legitimate websites and intercept and manipulate traffic between the user and the website, and violate the inherent trust that a user has in a particular organization.

The security of HTTPS is therefore determined by the security of the weakest CA. In fact, there have been several breaches of CAs in the past. Some examples include in 2011, there were 3 known breaches of Certificate Authorities; DigiNotar, Comodo, and GlobalSign, while in 2015 global security giant Symantec's CA was found to have issued over 100 SSL/TLS certificates for domains that it had not properly verified, including several Google domains. In 2016, the Chinese CAs StartCom and WoSign were found to have issued fraudulent certificates, backdated certificates, and otherwise violated industry standards. The incident ultimately led to the deprecation of their certificates by several browser vendors.

Obtaining a Rouge Certificate Issued By A Legitimate CA

Perhaps the most fundamental flaw with the established standard for verifying the authenticity of a website is that browsers inherently trust any certificate issued by a trusted CA. Well, after all, they are trusted, right? The browser doesn't know which trusted CA the legitimate domain owner obtained their legitimate SSL/TLS certificate from and it will trust any certificate signed by any trusted CA.

This opens attacks such as identity fraud and malicious domain verification where a malicious actor can get a valid certificate for your domain issued by a trusted CA and use it to spoof a particular website. If the attacker can trick the CA into thinking they are the owner of the domain, they can get a rouge certificate and every browser will trust it. Most of the time, the trusted CA only requires the most basic domain ownership verification before they will issue a certificate, and some CAs such as Let's Encrypt have automated and non-interactive software tools that issue certs without any sort of identity verification at all. 

If an attacker can gain access to an organization's web server, or other online accounts such as your domain registrar account (such as GoDaddy), or web-application firewall account (such as CloudFlare) they can add DNS TXT records to verify ownership and obtain rouge certificates to impersonate an organization's website. 

Rouge Nation States Own Trusted CAs

It is important to note that the ownership of a CA does not necessarily indicate its level of trustworthiness or security. One potential security risk of a state-owned Certificate Authority (CA) is the potential for political interference or pressure to issue certificates that may be used for malicious purposes. This attack scenario still requires a MiTM position in order to issue the rouge certificate and redirect the user to an attacker-controlled website. However, when you are visiting a foreign country with state-owned internet infrastructure you automatically forfeit that MiTM position, and everyone becomes a sitting duck. In this attack scenario, the end user's browser will not alert them about the hack. 

While some countries such as the US do not own certificate authorities, there are several trusted CAs that are owned by nation-states:

• Institute for Research in Fundamental Sciences (IPM): An Iranian state-owned Certificate Authority (CA). IPM is a research institution based in Tehran, Iran, and it provides digital certificates for websites and other online services in Iran. IPM is regulated by the Iranian government and is one of the few CAs in Iran that is trusted by major web browsers.

• China Internet Network Information Center (CNNIC): A state-owned organization under the Chinese government that issues digital certificates for domains registered in China.

• InfoCert S.p.A.: An Italian company that issues digital certificates for individuals and businesses in Italy that is partially owned by the Italian Ministry of Economy and Finance.

• National Informatics Centre (NIC): A CA owned by the Indian government that provides IT services to various government departments and issues digital certificates for government websites.

Are All Browsers Created Equally?

The simple answer is no. The major root certificate stores are Apple, Microsoft, Mozilla, and Chrome. Each of these root certificate bodies includes its own unique list of trusted Certificate Authorities which differ slightly.  As of April 2023, Microsoft has 447 trusted CA entities in its list, while Apple only has 173.

Defending Against a Poisoned Trusted CA Cache

Surprisingly, considering the potential threat that CA cache poisoning presents, there are few easily accessible methods or open-source tools for verifying the integrity of a browser's CA cache or verifying that the certificate being offered during an HTTPS connection has not been tampered with. However, there are some ways to protect yourself and your organization from this type of attack.  

Let's take a look at some defensive considerations in this matter.

• Keep your browser up-to-date: Ensure that your browser is always updated with the latest security patches and updates to mitigate known vulnerabilities and security weaknesses.  This reduces the potential for browser escape attacks and attacks that seek to directly poison the trusted CA cache.

• Use a trustworthy VPN: This measure is particularly effective against a scenario of cyber-attacks that target an HTTPS connection while visiting a country that has heavy national control over its internet infrastructure and also controls a Certificate Authority. Using a VPN will essentially move the location of the initial connection to the website to the location of the VPN server. It is important that the public key of the VPN is installed on your client before visiting the country in question to ensure your VPN connection itself is secure. It's also important to note that some countries such as China have strict laws that prohibit the use of some VPNs.

• Audit the integrity of your browser's trusted CA cache: Verifying the contents of the trusted Certificate Authority (CA) cache in a browser can be difficult because it is typically managed by the browser and while the user can access and view its contents, the task of manually verifying each item is infeasible.  However, there are tools such as Microsoft's certutil available that can be used to programmatically analyze and manage the trusted certificate cache.

• Custom software tools: None of the major browsers offer direct access to an HTTPS connection's SSL/TLS certificate information via plugins or browser extensions, making it difficult to analyze the certificate offered by a website each time you visit.  However, custom software tools can be used to detect if a website is consistently a certificate from the same CA or whether a connection might have an unexpected change. 

Conclusion

The standard for verifying the authenticity of a website we visit on the internet is not bulletproof. Attack scenarios against a browser's trusted CA cache do require the attacker to have a MiTM position to intercept and interfere with the victim's internet communication, but this fact offers little refuge There are several ways that attackers can surreptitiously compromise an HTTPS connection - tricking the unsuspecting user into thinking that their browser's approval of the issued certificate is sound, while in reality, it's checks have bee compromised.

There have been several breaches of trusted Certificate Authorities in the past and actually obtaining a valid certificate for a website is trivial if an attacker can compromise a web server or other online accounts with access to alter DNS records.  Other issues confound the ability to implement defensive measures as well. Verifying a browser's cache of trusted CA's is not a trivial task and defenders must instead rely on more complex solutions such as custom software implementations.

Looking for more updates on cybersecurity best practices? Sign up for our newsletter today for expertly-cultivated cybersecurity tips, news, resources, and more.