![Exploring Chrome’s New Root Store [Trust vs. Complexity] - cover graphic](/_next/image/?url=https%3A%2F%2Fcdn.venafi.com%2F994513b8-133f-0003-9fb3-9cbe4b61ffeb%2Fc6f08fb9-a05f-4890-a4cc-c8ee1a67b86b%2Faid_field_img__bd8700b819da571dab4a4c9aad46ab87.jpg%3Fw%3D864%26h%3D370%26fm%3Dwebp%26q%3D75%26fit%3Dcrop&w=3840&q=75&dpl=dpl_3EAuLccmwaq4KZ9GcZftJq5NbwLA){kind=small}
Google has recently announced a plan of creating their own TLS/SSL certificate root store for Chrome. This announcement constitutes a major change for the company’s browser, since up until now the Chrome browser has relied on the root stores of the underlying Operating System (OS).
What is a Root Store?
As discussed in a previous blog, a trust store or root store is a collection of root certificates that are trusted by default and maintained by the companies that make operating systems and web browsers, such as Apple, Microsoft, and Mozilla. These root certificates are used by operating systems and applications to verify the identity of a software program during its installation routine.
As mentioned in Mozilla’s Root Store Policy, “the included certificates have their 'trust bits' set for various purposes, so that the software in question can use the CA certificates to anchor a chain of trust for certificates used by SSL servers and S/MIME email users without having to ask users for further permission or information.”
Browsers like Chrome use root stores to check the validity of an HTTPS connection by looking at the website's TLS certificate and checking that the root certificate used to generate the TLS certificate is included in the local root store.
TLS Machine Identity Management for Dummies
What is the change?
Since its launch, Chrome was configured to use the root store of the underlying platform. For example, Chrome on Windows validated a site's TLS certificate against the Microsoft Trusted Root Program, the root store that ships with Windows, while on macOS the browser relied on the Apple Root Certificate Program.
All these are going to change, but currently there is no fixed timeline. Google’s announcement for the Chrome Root Program says that the new root store will ship with all versions of Chrome, on all platforms, except iOS.
The announcement defines specific rules and criteria for the Certificate Authorities (CAs) to be included in the root store approved list and notes that “Certification Authorities that do not meet all of the above criteria will be dealt with on a case-by-case basis.” The announcement goes on to specify that “The selection and ongoing membership of CAs is done to enhance the security of Chrome and promote interoperability; CAs that do not provide a broad service to all browser users are unlikely to be suitable.”
However, Chrome is not the first browser to take this turn. Mozilla has been including the root store inside Firefox since its launch. The reasons behind this decision are not specified in the announcement, other than that “This will ensure users have a consistent experience across platforms, that developers have a consistent understanding of Chrome's behavior, and that Chrome will be better able to protect the security and privacy of users' connections to websites.”
Having more monitors of root store trust can be a good thing, so I applaud Google’s move to expand the arbiters of trust. However, more parties involved may also lead to more complexity.
Is this as good as it sounds?
Despite the promising words of Google’s announcement, the change was met with skepticism. Catalin Cimpanu wrote for ZDNet that “One place where this move is expected to cause friction is in enterprise environments, where some companies like to keep an eye on what certificates are allowed in the root store of their devices.”
Martin Brinkmann agrees, stating that “One of the main reasons for [the change] is to ensure that the same root certificates are available on all platforms the browser is compatible with. [But] the transition to its own Root Store will add more to the workload of administrators."
In addition to adding more complexity in managing root stores, the problem of fraudulent certificates included in otherwise trusted stores is not going away. Another level of scrutiny, such as that offered by Google Chrome will help, but you will still need to maintain active vigilance to protect your business. “You shouldn't be trusting those that have nothing to do with your business operations,” says Kevin Bocek, vice president of security and threat intelligence for Venafi. That means it is the security leaders’ responsibility to understand and determine which entities they should trust.
They can begin by recognizing that trust stores come with hundreds of root certificates that are not necessary. In fact, a study by Leibniz University found that only two-thirds of the trusted root certificates included in the default trust stores were active in signing HTTPS certificates. That leaves the remaining third of trusted root certificates potentially vulnerable to abuses.
To address these potentially vulnerable certificates, organizations may consider rejecting these default trust stores. Alternatively, they could create a customized, corporate-level trust store using certificate whitelisting and determine which certificates are included. This practice helps organizations reduce their attack surface by limiting the number of trusted CAs and flagging untrusted SSL/TLS sessions. These organizations should then update these certificate whitelists and blacklists on an ongoing basis to reflect their evolving business requirements and the expanding CA landscape.
“If you don't take an active role in whitelisting and blacklisting the CAs in your trust stores—everywhere from the desktop to application servers to the cloud—you may end up incidentally trusting hundreds of CAs that you have no relationship with to enable others, including hackers, to be trusted. What you're essentially doing is letting somebody who knows nothing about your business determine who you will trust,” says Kevin Bocek.
Organizations should take steps to secure their own certificates and keys against digital attackers. They can do this by using solution that monitors these machine identities for signs of abuse. This platform should also automate the certificate renewal process to minimize the possibility of a human error. I would recommend a one-stop shop for all the above and more. Check out the Venafi Trust Protection Platform.
Get a 30 Day Free Trial of TLS Protect Cloud, Automated Certificate Management.
Related Posts