Even when the underlying certificate infrastructure is rock solid, enterprises can end up exposed because of loose coding prac-tices and improper design weaken cryptographic protections in common software such as Web browsers and mobile applications.
In the latest example of this problem, German researchers discovered that more than a thousand of the most popular free mobile applications on Google's Play marketplace fail to properly implement SSL and TLS. In a paper presented at the Conference on Computer and Communications Security (CCS 2012), the researchers, from two leading German universities, presented the results of an audit performed with an automated tool, dubbed MalloDroid. They found that 1,074 of the 13,500 popular free applications tested on Play has SSL and TLS implementations that left the applications open to man-in-the-middle attacks.
In many cases, application developers relied on dodgy SSL trust managers or hostname verifiers. Many applications didn't bother to perform authentication. Rather, they simply allowed the application to trust any certificate, regardless of who signed it, and any host that offered a certificate, regardless of whether the certificate offered was for the host offering it.
Application developers don't have a good understanding of cryptography or how PKI implementations work, GlobalSign's Hurst says. One reason is that the tools they use -- such as cryptographic APIs -- assume a high level of understanding of those topics. The result is shoddy SSL implementations.
"The problem with Android isn't so much irresponsible developers, but APIs that are designed for folks like me, not for your typical developer," Hurst says.
Five Steps To SSL Success
So what's a security-conscious company to do? Despite the many technical and organizational challenges involved with deploying a secure, reliable SSL infrastructure, organizations can take five simple steps to implement digital certificates securely and reliably.
1. Pick your CA carefully. As we noted, the market for certificates is competitive, and sometimes you get what you pay for. When picking a CA, do your homework.
"You're picking a business partner, not buying a product," Hurst says. "This is a relationship that goes beyond the delivery of a shrink-wrapped product. You have dependency on them long after they've issued you certificates." Look for CAs that are prepared to help you address issues such as key management, key revocation and phishing.
2. Prepare for the worst. If the past year has taught us anything, it's that the once boring and staid world of issuing SSL certificates isn't so boring anymore. Many organizations that relied on the DigiNotar CA -- the Dutch government among them -- found themselves in a quandary when that CA failed. They were unsure of how many certificates they needed to cancel and reissue, and they lacked a quick back-up plan. It can take days or weeks to get up and running with a new CA and replace all of your certificates, Venafi's Turner warns. And, if a CA has been compromised, you probably won't be the only organization scrambling for a safe harbor. Turner recommends having a back-up CA, with a list of domains you need authorized and the ability to churn out replacement certificates on short order.
3. Know your environment. A first step to SSL sanity is knowing which certificates are floating around in your organization's name. That list should include certificates issued by public and internal CAs. Do an inventory, reviewing all of your applications and servers, noting any certificates they pass and any they accept from "relying parties" -- the individuals and systems that electronically interact with the certificate holder. Next, identify and document who the system and application owners are and how to contact them. Document which CAs issued certificates, their expiration dates, the algorithms used and key lengths.
Finally, document the trust anchor for each CA -- the CA that would be used to validate the certificate (typically, the root CA) and make sure you have the contact information for that organization and know the procedures necessary to revoke and replace any compromised certificates.
4. Have a key management strategy. One of the biggest exposures large companies have to SSL risk is through their critical, legacy internal applications. Many of these companies use SSL or SSH (Secure Shell) encryption to secure communications with users and with other systems with which they interact. However, most organizations have only a cursory understanding of how those keys are implemented.
Companies rarely have a way to change the many old, easy-to-break embedded keys and insecure protocols they have in use, and they're wary of incurring downtime to do so. Address the problem head-on by making an inventory of the encryption keys used within your application infrastructure, assessing their strength and security, and devising a plan to replace weak keys and strengthen protections for all your keys, such as with a hardware security module.
5. Clean up SSL deployment and implementation. Misconfiguration of SSL servers is endemic. As Qualys's SSL Pulse tracker has shown, many companies continue to rely on or support outdated protocols and vulnerable ciphers. Our experts recommend performing an audit of your public and private SSL deployments, ensuring that they meet industry standards for secure implementation. Make sure that your SSL implementation uses secure protocols and unbreakable ciphers, and that you're using SSL to encrypt all of the traffic from your website. For internal or special-purpose applications, consider limiting the list of supported CAs to limit your exposure to forged certificates.
Platform vendors such as Apple, Google and Microsoft would do well to create APIs and other development tools that enforce best practices, make it easy to understand configuration changes that can increase security, and limit the options available to average developers.
Sidebar: Beyond SSL: The Convergence Project
The compromise and eventual collapse of Dutch certificate authority DigiNotar was a disaster for the tens of thousands of private and public sector organizations that relied on the CA to vouch for their online identities. Furthermore, many governments -- including Iran and China -- maintain their own CAs, which are recognized by software publishers and browsers but can become problematic in the age of state-sponsored attacks.
Enter Convergence, the brainchild of SSL security expert Moxie Marlinspike. Based on research done for the Perspectives Project at Carnegie Mellon University, Convergence aims to replace the static list of trusted CAs with a dynamic, global network of "notaries" who vouch for the identity of a given website.
Convergence provides what Marlinspike calls "trust agility." Users choose which notaries they trust and for how long -- granting and revoking trust themselves, rather than deferring trust decisions to browser makers, governments and other authorities.
For now, Convergence is in the beta stage, with two notaries (Marlinspike's Thoughtcrime Labs and security firm Qualys) and a free Firefox plug-in. However, the plan is to get more notaries to sign up, expand Convergence to work with more browser platforms and begin offering Convergence as an alternative to certificate authorities.