Web Encryption That Works

Download the entire Dark Reading March 2012 Supplement

For years, Secure Sockets Layer encryption methods have been fundamental to Web security. Recent attacks have called into question whether SSL and the follow-on protocol, Transport Layer Security, are the best ways to authenticate websites. Critics say these methods are vulnerable and difficult to deploy, but most industry experts insist they aren't fundamentally broken--they just need to be implemented better.

SSL and TLS, both commonly referred to as SSL, are being used in all corners of the Web to authenticate that a website is actually the one it says it is and not a fake launched by phishers and other attackers to obtain confidential data. SSL also provides the encryption infrastructure to share data securely. It's so entrenched, and the prospect of ripping and replacing it with a different technology so onerous, that a wholesale change to a new method isn't likely to happen. Given its ubiquity, improving how website operators deploy and implement SSL looks like our best choice in the near term. (Read more on future prospects here.)

"Even if we did decide that it's fully compromised and broken right now, it would probably be 10 years before you could actually have something meaningful replacing it if you started today," says Brian Trzupek, VP of managed identity and authentication for Trustwave, a certificate authority and security services vendor. The most recent version of SSL-based technology--TLS 1.2--has fixed the known problems. The vulnerabilities that remain are "in the periphery of how SSL is implemented," says Trzupek.

The SSL trust ecosystem isn't perfect, but there are steps website operators can take to optimally deploy SSL, avoiding mistakes that can jeopardize companies' data and put customers at risk. Here are four places to start.

Use Up-To-Date Protocols, Cipher Suites

SSL is an elegantly engineered protocol that can withstand many types of attacks. But that statement comes with one big caveat: To be fully protected, a website must use the most up-to-date SSL protocol and cipher suites, and its servers must be properly configured.

But many IT organizations don't do a good job with this. "Most SSL servers are misconfigured," contends Ivan Ristic, director of engineering at Qualys, an IT security services provider that has scanned 1.2 million website servers to study SSL deployment trends. "Only about one-third of the servers we saw that use SSL are properly configured. That's the best we can do at the moment."

The vast majority of servers still use a version of SSL that's two revisions behind the most current technology, according to Qualys. In the same way it's critical to patch endpoints with the latest, most secure software updates, it's important for companies to use up-to-date versions of SSL to minimize vulnerabilities that attackers can leverage to carry out session hijacking and other sophisticated attacks.

Similarly, businesses need to think carefully about the cipher technologies they're using with the SSL protocol that do the actual encrypting.

"Try to choose the biggest, most complex encryption keys you can that will reasonably work on all of the devices they need to work on," Trzupek says. Ideally, companies should use 256-bit cipher strength or stronger.

This is a big factor in properly configuring SSL on a Web server, Ristic says, but there are plenty of other areas to watch for, especially at the application layer.

Of the SSL-enabled sites that Qualys examined, SSL generally wasn't implemented well at the application layer, he says. Even sites that have well-configured SSL at the protocol level often construct the Web applications and sites in ways that "completely compromise SSL and make it easy for an attacker to exploit that problem," he says.

For example, many Web applications fail to encrypt the authentication form that gets users started using the app. "It surprised even us," Ristic says. "People are entering their user names and passwords in plain text, and attackers are routinely catching those."

Another common misconfiguration is not adequately securing session cookies when they're deployed, giving attackers easy access to them. Cookies must have the word "secure" coded into them in order to be safe from prying eyes. "Even if you have a well-configured SSL server, if you don't mark your session cookies secure, ... an attacker may be able to take the cookie out and hijack the session," Ristic says. Developers need to watch for these errors when creating new applications, he says. With existing applications, it's much more difficult to retrofit fixes every time a vulnerability is identified.

Manage Encryption Keys Properly

Encryption brings with it administrative baggage. One of the biggest hassles is managing the public and private keys that are used to encrypt and decrypt information as it moves between websites and users. End users employ a public key to encrypt data they transmit to a website's server, and the website uses a private key to decrypt that information and display whatever users would like to see on their browsers.

Private keys in particular must be secured from attackers and rogue insiders. Anyone with access to a private key has access to the certificate that accompanies it; certificates are confirmations from a third-party certificate authority (CA) verifying that a website is legitimate. An attacker can use a stolen private key and the accompanying certificate to authenticate a fake website so it mimics the legitimate site and fool visitors into thinking it's the real thing and handing over valuable data.

But securing private keys makes managing a website more difficult, raising the classic conflict between security and convenience. SSL Web servers need to be able to access private keys without having to rely on IT administrators getting involved. Site operators often take shortcuts, storing keys with little or no security so as not to interrupt Web content delivery to end users.

"You need those keys to be available when you need them," says Jeff Schmidt, founder and CEO of JAS Global Advisors, a consulting firm specializing in IT, risk governance, and strategic technology risk. "At the same time, you need to make sure that only the people you want to have them have them." At most companies, the private key sits unencrypted on the Web server so it can boot without somebody using a password, smart card, or other device that requires a login and password, Schmidt says.

What that means is that when a Web server is compromised--which will inevitably happen at some point, given today's threat environment--the attacker gains access to those keys and can use them to set up a fake server. And while most website operators know that when a Web server is compromised, a new virtual machine should be reimaged with new certificates and private keys, they often don't bother to change the certificates and keys.

"We've seen instances where a Web server was compromised, a new server was set up, but the certificate wasn't changed and the bad guy has the private key," Schmidt says. And with that key, the attacker can easily continue creating forged certificates and impersonating the site.

One obvious way to protect public and private keys is to never store them on the Web server. The private key especially should be stored elsewhere. Similarly, don't store the private keys on FTP servers or email them to people for any reason. Using these insecure channels for key sharing or storage leaves them available to hackers, as well as anyone inside the company with a little knowledge of the SSL-protected systems. "All of a sudden, you've blown your security scheme and your auditability and everything else," says Jeff Hudson, CEO of Venafi, an encryption management vendor.

The solution is to use a key management tool to segregate public and private keys, and ensure that the people who manage the SSL systems don't have access to the private keys. Site administrators should not also be the key administrators; keep those jobs separate.

Take Care With Certificates

In addition to poorly managing encryption keys, operators of SSL-based websites often do a poor job managing the certificates themselves. Certificates can number in the thousands or even tens of thousands at businesses that run secured intranets, large e-commerce sites, or other websites handling sensitive data. When dealing with huge numbers of certificates, companies often spread out the responsibility across server and website owners, and that can quickly lead to chaos.

Big retailers and other companies often don't even know how many certificates they have in place, Hudson says. One large retailer recently told him it had 15,000 certificates. When his team checked the retailer's infrastructure, it found double that number. According to a survey out recently from Osterman Research and Venafi, 54% of organizations don't have an accurate inventory of their digital certificates.

One critical problem with distributed certificate management is that no one person or group is tracking the expiration dates of the certificates. They often expire without anyone noticing, and then customers and other users trying to access information get alerts that a certificate is questionable, or they can even be blocked from accessing the information they need.

"What ultimately happens is the cert goes down, a bunch of customers get blocked, there's phone calls, heads rolling, they renew the cert and get it back on there," Trzupek says. In the meantime, the company looks bad every time a customer gets a security warning that a certificate has expired.

You also don't want the situation where customers and other users get expired certificate warnings about your site so often that they come to expect it and automatically click "OK." That undermines the certificate verification process and leaves your site completely vulnerable in the event of an attack.

In addition to not tracking their certificates, many companies either don't have policies or don't enforce existing policies on how certificates are purchased and from whom. Programmers in a hurry to launch a website go to any CA that will quickly provide a certificate, without regard for whether it's on their company's list of approved CAs. But a random certificate from a CA with a poor reputation may not be as safe as one from a reputable CA with better security standards.

Many organizations face just this sort of internal policy enforcement problem, Hudson says. For example, a manager at a large e-commerce outfit claimed to have solid policies that dictated who could install certificates and where they could get them. But Hudson's staff found on its sites several certificates that didn't conform to that policy, using a vendor not on the approved list.

"We said, 'Excuse me, but we did this scan yesterday and found these three Go Daddy certificates,' and this guy stood up, pounded his fist against the desk, and said, 'I told those guys not to do that,'" Hudson says.

When certificate management is done manually and policies about the provenance of a certificate are not enforced, organizations are opening themselves to the risk of not knowing whether or not they're exposed when a CA vendor is breached, as in the cases of DigiNotar and Comodo last year. The Venafi-sponsored Osterman survey showed that 72% of organizations don't have an automated process to replace certificates if one of their CA vendors is breached.

To get control of the certificate management process, consider tools to automate the certificate discovery process. These tools scan for certificates and set up an automated system that handles renewing them as they expire. Once that's done, centralize the whole process, ideally using a certificate management platform that lets a central administrator manage all the certificates, issuing them to business units and server owners as they request them, and enforcing company policies organization-wide.

"You want a platform that can accommodate one administrator who oversees all of the different certificates but can also be distributed so that individuals who are responsible for individual servers can tap into a centralized system and make their request," says Deena Thomchick, director of product marketing at Symantec. Entrust, RSA, Symantec, Trustwave, and Venafi are among the companies offering certificate life-cycle management systems.

TOP OF THE SSL CLASS

IT security services provider Qualys has evaluated the SSL implementations of more than 300,000 Web servers, and it gives only 32% of them an A grade for proper configurations.

Qualys's SSL Labs group first checked that each site's certificate was valid and trusted by a reputable certificate authority. Any site that failed this step was automatically assigned a total score of zero.

The sites were then evaluated in three areas: protocol support, key exchange support, and cipher support. A zero in any category gave the site a zero total score, and 100 points were possible.

The servers receiving a B or lower most often just use the default settings of their Web servers to configure SSL, Qualys says.

Avoid Mixed Content

Mixed content is when companies use SSL on one page within a website but serve up content on that page that isn't SSL-protected. That introduces gaps that can be exploited. Attackers can intercept unencrypted content and alter it for their purposes. If the unencrypted portion of the site can run scripts, hackers can carry out dangerous attacks, such as DNS poisoning attempts in which website traffic is diverted to the attackers' site.

Any time you have an SSL-secured HTTPS connection, you shouldn't have content pulled in from other places on your domain that is sent only over unprotected HTTP, says Nicholas Percoco, senior VP at Trustwave's SpiderLabs research division. "You want to make sure that all pages are over SSL and are tested," he says.

Similarly, make sure that all forms you have customers and other users submit use SSL, so that if, say, a customer clicks into a "Contact Us" link in the middle of an e-commerce transaction, there won't be a warning saying, "Part of the Web page you're browsing is unencrypted."

The mixed content issue is particularly a problem with Extended Validation SSL certificates, Trzupek says. EV SSL certificates are a level up from regular, and more commonly used, Domain Validation SSL certificates, which ask for minimal validation that you are the person who owns the rights to the domain to be secured by the SSL certificate. EV SSL certs cost more and require an extensive application process for site owners to prove they are who they say they are. Sites using EV SSL certificates have a green bar that shows up on their browser address bars to indicate they're EV SSL-protected. Regular Domain Validation SSL is indicated by a padlock.

If you put an EV certificate on a site and then include a JavaScript resource that's just SSL secured, that's going to downgrade the browser experience to normal SSL, Trzupek says. "A lot of organizations ... buy a wonderful EV certificate, put it on their marquee brand website, and the bar ain't turning green, and they can't figure out why."

Many certificate authorities have lowered prices on additional EV certificates once a company initially buys into EV SSL in order to lower the cost of deploying EV certificates across a site, Trzupek says. But it remains a problem because many website operators don't know to watch out for mixed content.

Vigilance is really the only way around the mixed content problem. Companies must have in place an extensive testing and quality-assurance process that ensures that mixed content isn't allowed in site and app development.

Tim Moses, director of advanced security at Entrust, typically sees two kinds of customers buying certificates today: First are those who want the marketing boost that comes from the trust indicator--either the green bar or the padlock--"and they'll do whatever it takes to get that indicator," he says. "And then there are the other site operators who really take their end users seriously and do whatever they can to protect them against attack."

So which is your company? If it's only after the marketing boost, be aware that just buying EV certificates won't fully secure your website. You must also consider how your SSL servers are configured, how keys are managed, how certificates are purchased and managed, and whether your site serves up mixed content. These steps are essential to taking control of your company's Web encryption.

10 COMMON SSL MISTAKES

Tim Moses, a director at the encryption vendor Entrust and chairman of the standards-setting Certificate Authority/Browser Forum, offers these missteps to watch for.

1. Unpatched servers, particularly on high-traffic sites.

2. Sensitive scripts and forms hosted on unsecured pages. Login pages, in particular, that aren't protected by SSL are vulnerable because they include user names and passwords.

3. Weak cipher suites that don't include the most up-to-date encryption technology.

4. Unsecure handling of private keys, including the use of email to share them among system administrators.

5. Serving secure and unsecure content on the same Web pages, letting attackers easily inject content.

6. Expired or otherwise invalid SSL certificates, since they can train people to ignore warnings.

7. Using domain validation certificates for e-commerce sites, rather than more secure extended validation certificates.

8. Having a certificate for www.example .com, but not example.com, which users might type in instead.

9. Not ensuring that cookies are secured.

10. Copying keys and certificates to multiple servers, losing track of their location, and failing to anticipate expiration.