SSL/TLS, long the cornerstone of Web security, has become a security vulnerability due to problems with certificate authorities. Learn what solutions the industry is pursuing.

Confidence in the Transport Layer Security and Secure Sockets Layer cryptographic protocols has taken a real hit over the last few years, particularly SSL, the predecessor of TLS. Bugs discovered in cryptographic software libraries that implement the SSL/TLS protocols like Apple's SecureTransport, OpenSSL, GnuTLS, Mozilla's NSS and Microsoft's Secure Channel have had vendors and administrators rushing to mitigate potentially serious flaws that threaten networks, users and their data. On top of that, recently discovered vulnerabilities such as POODLE allow direct attacks on the SSL protocol itself.

All this has led the National Institute for Standards and Technology (NIST) to recommend that government agencies develop migration plans to move to TLS 1.2, while the PCI Security Standards Council (PCI SSC) has released an unscheduled version of the Payment Card Industry Data Security Standard (PCI DSS 3.1) requiring merchants to phase out the use of SSL and early TLS by June 30, 2016.

The current version of TLS, version 1.2, is still considered secure but the Transport Layer Security Working Group of the Internet Engineering Task Force (IETF) is already working on TLS 1.3 to further improve security, reduce the chance of implementation errors, and remove unnecessary features and functions.

Certainly, deprecating and replacing SSL will help resolve many SSL-related vulnerabilities,but there are growing concerns about the trustworthiness of the digital certificates that underpin the trust and security of SSL/TLS communications. It's important to understand these certificates and what they have, and have not, accomplished in the quest for Internet security.

What CAs did and didn't accomplish

Digital certificates solved the biggest barriers to using the Internet: how to know that a website is what it says it is and that communications with the site are private. Virtually every device that is connected to the Internet contains a list of trusted root certificate authorities (CAs), allowing it to verify the validity of a certificate through a chain of trust right up to the trust anchor -- the root certificates that it trusts. This trust model relies on CAs having robust and secure infrastructures and certificate issuance procedures to minimize the possibility of fraudulent certificate issuance.

Sadly many CAs are failing on both fronts. A growing number of certificate authorities, Comodo and DigiNotar to name just two, have been attacked and compromised over the last few years, allowing hackers to digitally impersonate organizations like Facebook, Twitter, Skype, Google and the CIA. Cybercriminals and state-sponsored hackers are actively stealing and abusing digital certificates to carry out cyber espionage, man-in-the-middle (MitM) attacks, sabotage, and malware distribution -- the use of certificates to make malware appear as legitimate software has grown 700% during 2012 to 2015, according to the November 2014 McAfee Labs Threats Report.

Various CAs have also been guilty of poor practices. DigiCert mistakenly sold a certificate to a non-existent company, which was then used to sign malware used in cyber-attacks. Human error was the reason given for an intermediate CA certificate of ANSSI, the French cybersecurity agency, which was used to generate fake certificates used to carry out MitM attacks. Another, more recent, case involved the issuing of unauthorized digital certificates various Google domains by Egypt-based MCS Holdings, an intermediate certificate authority that operates under the China Internet Network Information Center (CNNIC). As CNNIC is included in root stores for virtually all OSes and browsers, almost all browsers and operating systems would trust these "mis-issued" certificates.

Fixing the certificate authorities fail

There are various initiatives underway to try to improve the trust in CAs, their certificates and how they're verified. Venafi TrustNet operates a global authoritative key and certificate reputation service that identifies rogue or anomalous key and certificate usage, while Google is trialing Certificate Transparency (CT) to help detect and counter fraudulent and stolen certificates. It is an experimental protocol for publicly logging every certificate that's issued by compliant CAs, the idea being that browsers will refuse to honor certificates that do not appear in a public CT log.

The Public Key Pinning Extension for HTTP is another approach to curtailing certificate fraud. It allows a site's administrator to "pin" a CA's certificate or public key to their server's certificate and send this information in an HTTP header. This means browsers and other apps can check that a server's certificate is signed by a particular whitelisted CA instead of relying on certificate chain verification to validate it. Another new protocol is DNS-based Authentication of Named Entities (DANE), which enables certificates to be bound to DNS names using Domain Name System Security Extensions. This allows clients and servers to authenticate each other without having to reference third-party certificate authorities. Although DANE promises more direct authentication, it will give DNS operators an even bigger role in keeping the Internet secure.

What's an InfoSec pro to do?

Browsers and other software base trust decisions on the certificates in their root store, so the best way for enterprises to safeguard their users and network devices from rogue certificates and trust-based attacks is to ensure that software is kept up to date with current certificate trust lists (CTL).

Security teams should also monitor security news feeds and delete untrusted root certificates from root stores manually before updates become available if the risk to a network is deemed unacceptable. Instructions to remove a root and clear the local cached CTL across an enterprise network can be issued via group policy.

Enterprises should also audit their data centers, applications clouds, and mobile devices to ensure their asset register of digital certificates is up to date and all are installed correctly. The average enterprise has thousands of keys and certificates, but IT pros in the majority admit to being unaware of where all of their keys and certificates are located, who owns them or how they are used.

The current CA-based system of trust is not perfect, and so far attempts to improve it have failed to find a consensus among the major Internet players; the result is a patchy implementation of different protocols and ideas. For now, enterprises need to remain vigilant in monitoring the latest intelligence on certificate-based attacks and do all they can to securely manage their own CAs.

About the author:Michael Cobb, CISSP-ISSAP, is a renowned security author with over 20 years of experience in the IT industry. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. He was also formerly a Microsoft Certified Database Manager and a registered consultant with the CESG Listed Advisor Scheme (CLAS). Cobb has a passion for making IT security best practices easier to understand and achievable. His website is www.hairyitdog.com.

Join the conversation

2 comments

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Your password has been sent to:

Please create a username to comment.

Contractor, doing PKI support for a government agency. That agency has a policy which restricts the PKIs its people are supposed to use to PKIs that are specifically vetted. I.E., does not rely on the decisions by third parties (Microsoft, Apple, Mozilla) as to what PKIs it should trust.

That is not a trivial undertaking - but, by pruning the trust stores delivered by the browser vendors and NOT allowing auto updates, it believes it is more secure than organizations that trust everything the browser vendors decide is OK (which, as noted in the article, has sometimes failed at protecting you!)

The practice by security professionals ought to be to KNOW what is in your trust lists, pruning out the trust anchors that aren't needed and only including ones that you know are needed and have vetted to be sure they meet YOUR security standards (and not those of a third party you do not control). That is not easy. It is not made any easier by what PKIs make available in terms of certificate policies, practices and audit data.

And, it will cause your users problems when they go to a web site NOT in the approved list - but, as also noted, interoperability (aka making it easier for the users to go where they want without controls) often results in security issues...