Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


06:30 PM
Connect Directly

What You Should, But Don't, Do About Untrusted Certs, CAs

Security departments could take measures to protect organizations from untrusted certificate authorities and counterfeit SSL certs, but most don't bother.

Despite worries about counterfeit certificates and man-in-the-middle attacks on SSL communications, many security professionals are doing little to protect their organizations from the dangers of untrusted certificates and certificate authorities (CAs), according to new research by Venafi.

Venafi surveyed 333 attendees to the Black Hat USA conference in Las Vegas last month about their perceptions and practices regarding CAs, the arbiters of online trust, which themselves may not always be trustworthy.

One of the most recent events jeopardizing the sanctity of certificates happened in March, when MCS holdings, an intermediary for the China Internet Network Information Center (CNNIC) CA, began issuing unauthorized certificates for Google domains (which could be used for man-in-the-middle attacks). Google responded by removing CNNIC from Chrome's list of trusted root CAs; Mozilla also refused to accept CNNIC certificates issued before April 1.

Another defining event was in 2011, when attackers breached Dutch CA DigiNotar and issued over 500 counterfeit digital certificates for some high-profile domains; DigiNotar went out of business the very next month. Ninety percent of respondents to Venafi's survey expect that within two years a "leading CA" -- perhaps Comodo, Symantec (which purchased Verisign), GoDaddy, GlobalSign, or DigiCert -- will be breached. Yet, respondents' readiness to respond to such a breach was insufficient.      

Here's what you need to consider, according to Venafi VP of security strategy and threat intelligence Kevin Bocek.

Emergency Change of the CA That Issues Your Company's Certs

What if DigiNotar or CNNIC had issued the certificates your own organization used to secure your communications with customers? Once the CA is compromised, browsers and your customers begin declaring that CA -- and thereby your company -- "untrusted." Customers' access to your website may be restricted. Therefore, says Bocek, you should be ready to shift your keys and digital certificates to a new CA right away.

However, according to the Venafi survey, only 9 percent of respondents said they would use an automated system to replace keys and certificates. Most would rely on manual processes, 23 percent said they would hire an insider response firm to replace keys and certificates, 24 percent said they didn't know what they would do, and 6 percent admitted they would just continue to use the untrusted certs.

Bocek recommends following the guidance NIST developed after the DigiNotar incident, "Preparing for and Responding to Certification Authority Compromise and Fraudulent Certificate Issuance." The guidance, he says,  boils down to "know what you've got, have a relationship with someone you can switch to, then switch to them."

Remove Untrusted Certs From Your Trusted List

Venafi asked Black Hat attendees what action they took after the CNNIC incident. Most (34 percent) weren't sure, 23 percent said they did nothing at all, and 17 percent said they waited for Apple and Microsoft to act (the remaining major browser developers after Google and Mozilla, which had already acted).

Only 26 percent said they removed CNNIC from their list of trusted CAs on devices, and Bocek believes even that is "wishful thinking on the part of the respondents. I think that is an overestimation. I think that's what they'd have had liked to have done," but in actuality, he says, even fewer took that action.

Bocek points out that your devices -- particularly mobile devices -- probably already accept way more certs than you realize, and more than you require. Venafi asked respondents to estimate how many certificate authorities were trusted by mobile devices. To Bocek's surprise, respondents thought mobile devices trusted only two-three CAs, when in reality, iOS alone trusts over 240 CAs, including dozens run by international governments.

Further, all these trusted CAs are trusted equally -- but do they have equal fraud controls? "The answer, I already know, is no," says Bocek.

The U.S. government is concerned enough about the issue that the House of Representatives' Energy and Commerce Committee wrote letters to Apple, Google, Microsoft, and Mozilla in June, stating "our concern with CAs' unfettered authority to issue certificates is heightened when the CA is owned and operated by a government."

Protecting Keys And Certs On Your Internal Systems 

Bocek reminds security professionals that they, not CAs, are also stewards of keys and certificates, and therefore responsible for their safety. In fact, Venafi's survey found that security pros may overestimate what CAs actually do to protect and monitor use of them.

As the report states, "CAs only issue and revoke certificates—they don’t monitor their use beyond
that in the wild and ultimately cannot provide any security for them." Yet, when asked "does your CA protect you from theft or forgery of digital certificates," 29 percent mistakenly answered yes and 34 percent said they didn't know.

Bocek recommends security managers review the updates to number 17 of SANS 20 Critical Security Controls for guidance. 

Any CA Breach Can Hurt You

Consider that some CA you've never even heard of is breached and attackers start issuing counterfeit certificates claiming to be from your company, putting your customers at risk to MITM attacks. If you're Google and happen to run your own browser, you can help yourself out by yanking that CA from your trusted list, like they did with CNNIC. If you don't happen to be a developer with millions of customers, you can do... what?

"They could issue a cert for you and there would be nothing you could do," says Bocek. "You could be impaired by a breach at an organization that you have no relationship with. This is a new problem that we're only starting to understand."

Bocek says, "I think it's something that would scare board rooms."

Sara Peters is Senior Editor at Dark Reading and formerly the editor-in-chief of Enterprise Efficiency. Prior that she was senior editor for the Computer Security Institute, writing and speaking about virtualization, identity management, cybersecurity law, and a myriad ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Ninja
9/10/2015 | 7:39:06 AM
amid piles of certificates which are actually valid
one of the big troubles with x.509 certificates is that you cannot tell the difference between a correct certificate and a fake just by looking at it

first off you likely don't know what the certificate is supposed to look like

second, even if you did know what the certificate is supposed to look like a digital forgery can be presented

you need to check the "fingerprint" that appears on the certificate,-- which looks like this :

EB17 451D CBD3 089F 8095 500E F6E9 41B1 4DEA 0DAD

you also need a reference to check it against

the good news though is that from the pile of x.509 certificates that you have in your browser you likely need to hard-verify only a handful: those that deal with money.   credit union, IRS, online shopping, --that sort of thing.    these services need to help customers with fingerprint checking.    perhaps near-field radio could be incorporated into a digital-keychain product.

in the Army we used to have a special device for carrying our digital keys.     Perhaps we should review this thought.

i would not use my smartphone for this nor recommend anyone use their smart phone, tablet  etc for that purpose: these devices are too likey to be pwned -- because they have too many "apps" on them .    we need a device that does one thing -- and does it well.   you will use that device to update the certificates in your other devices .

your electronic key-carrier would then (1) validate a certificate for you, and then (2) countersign that certificate making it fully trusted.   all of the other certificates loaded into your browser by your software OEM would remain at marginal trust only -- and not acceptable for any application dealing with money.     if you want to use a secure certificate for e/mail that ought to be an option .
User Rank: Apprentice
9/9/2015 | 10:41:52 PM
Reappearing certs
I don't know if this is still true; however, I used to delete all of the certs that I perceived to be untrustworthy. However, every time I updated the browser (didn't matter if it was IE, Firefox, or Chrome), the certs would reappear.
Why Vulnerable Code Is Shipped Knowingly
Chris Eng, Chief Research Officer, Veracode,  11/30/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: I think the boss is bing watching '70s TV shows again!
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-12-03
Pimcore is an open source digital experience platform. In Pimcore before version 6.8.5 it is possible to modify & create website settings without having the appropriate permissions.
PUBLISHED: 2020-12-02
PHP remote file inclusion in the assign_resume_tpl method in Application/Common/Controller/BaseController.class.php in 74CMS before 6.0.48 allows remote code execution.
PUBLISHED: 2020-12-02
The Victor CMS v1.0 application is vulnerable to SQL injection via the 'search' parameter on the search.php page.
PUBLISHED: 2020-12-02
SQL injection vulnerability in BloodX 1.0 allows attackers to bypass authentication.
PUBLISHED: 2020-12-02
An SQL injection vulnerability was discovered in Online Doctor Appointment Booking System PHP and Mysql via the q parameter to getuser.php.