Certificate reputation services can end the risk that certificate validation app developers face (and are not doing a good job of addressing)
The OpenSSL team has released a fix for a critical vulnerability that could allow an attacker to trick an application into trusting a forged certificate—lovingly called by some “OprahSSL” for its propensity to gift something valuable. Why is this so important? Why does it matter? The big story is not just this vulnerability: it’s the ongoing difficulty for apps to validate certificates and know what should be trusted.
FireEye found that 73% of the top 1,000 apps don’t even validate certificates. This lack of attention to checking what should be trusted and what shouldn’t got Fandago and Credit Karma a special 20-year relationship with the U.S. Federal Trade Commission (FTC). This occurred simply because their mobile apps didn’t validate certificates—meaning their mobile apps might be sharing credit card data and sensitive personal information with bad guys without a concern for the consequences. This is a problem for not just enterprise CISOs and IT security teams, but also commercial app developers, fraud prevention, and chief privacy officers (CPOs).
 |
| Native iOS apps by default can’t even identify a website with a revoked certificate as being non-trusted |
The OpenSSL vulnerability is a clear reason why certificate reputation, now available to enterprises with Venafi TrustNet, is so important. TrustNet uses advanced algorithms as well as big data and cloud-based intelligence to validate digital certificates rather than static code that, for even advanced security professionals or developers, is confusing, at best. The complexity and vulnerabilities like this one perpetuate the “blind trust” we place in certificates today. We’ve been validating certificates in pretty much the same way for over 20 years—what do most professionals trust in cybersecurity that’s been done the same way for just 2 years, not to mention 20? Certificate reputation services like TrustNet dramatically reduce risk.
OpenSSL’s Certificate Validation Vulnerability
For details on versions affected and patches available, get the details from OpenSSL at https://www.openssl.org/news/secadv_20150709.txt.
Unlike Heartbleed, with this vulnerability, keys and certificates are not directly exposed and do not need to be rotated. The vulnerability impacts client applications validating certificates, such as a browser, VPN, or mobile application, that use the OpenSSL libraries for SSL/TLS sessions. It also impacts server applications, like a webserver or VPN, that authenticate digital certificates presented by client applications.
This vulnerability shows again why we need to know what certificates are in use and what certificates are trusted and where. And we need this everywhere—on our servers, desktops, and around the world on the Internet.
Exploiting the Vulnerability
To exploit the vulnerability, an attacker needs to obtain a private key for a certificate issued from a trusted certificate authority (CA). This could be a public third-party CA trusted across browsers and the Internet, or a private CA used and trusted inside your organization. The vulnerability allows the certificate associated with the obtained key to be used as if it were a CA, even though it’s not. This means any type of certificate from a webserver to a VPN certificate could now become a trusted CA issuer.
An attacker could then forge certificates for any domain, website, or user they’d like, including you and your businesses or government. This could prove useful in executing man-in-the-middle attacks, spoofing, spear phishing, and other attacks. And it’s easy to do: OpenSSL is the perfect tool to generate keys and sign a certificate.
It’s also easy to obtain a key from a trusted CA. Depending on the end target, I might just buy a certificate from a trusted third party. If I need the certificate to chain up under a specific CA and don’t want to/can’t buy one reputability, I can easily go the underground market where stolen certificates go for $1000 or more. Or, because thousands of Trojans support the collection and extraction of keys and certificates, the job is pretty easy.
 |
| Native iOS apps perform little to no checking as to whether a certificate is truly valid or not, unlike certificate reputation services like Venafi TrustNet |
Certificate Reputation Ends the Age of Blind Trust
Today, using Venafi TrustNet certificate reputation APIs, you can validate if a certificate should be trusted or not. This is independent of the static code or rules that might later be vulnerable, like today with OpenSSL or other libraries. Offloading these decisions to an intelligent reputation system mitigates risks of these vulnerabilities in certificate validation that are complex and difficult for even the smartest developers. The TrustNet API can be called from any application, whether a mobile app or container-based service application in the cloud. It’s one API call that takes care of all decisions about certificate chain validation, trust, validity, fraud, and vulnerabilities. Amazing! That’s the power of Venafi as the Immune System for the Internet.
Additionally, with Venafi you can discover what certificates are in use and what CAs are trusted across your organization and then whitelist or blacklist CAs. You can then enforce a policy to not trust particular CAs that your business or government finds untrustworthy, like the Chinese CA CNNIC.
All of these reasons are why Venafi as the Immune System for the Internet is critical to protecting the world’s economy today and in the future. Outside of Venafi there is no system that understands what should be trusted, what is trusted, and can fix it—whether inside the enterprise or outside across the Internet.
Like to learn more and continue the conversation? Drop me a note.