Endpoint
2/23/2012
01:50 PM
Connect Directly
Twitter
Twitter
RSS
E-Mail
50%
50%

Web Encryption That Works

SSL technology isn't perfect, but it can be an effective security tool for your organization. Here are four tips for optimizing its performance

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.

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Previous
1 of 4
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Georgeken
50%
50%
Georgeken,
User Rank: Apprentice
3/22/2012 | 10:38:18 AM
re: Web Encryption That Works
Encryption lock is needed and it will not leak out the information
cgoforth666
50%
50%
cgoforth666,
User Rank: Apprentice
2/28/2012 | 5:02:16 PM
re: Web Encryption That Works
We have been having some discussions on SSL.-á Could someone please tell me what strong ciphers
should be allowed on public facing HTTPS web sites? -á-áAlso why donGÇÖt people recommend only using a
few suites like DES, RC4 or AES instead of allowing all of them?
MS8699
50%
50%
MS8699,
User Rank: Apprentice
2/27/2012 | 8:55:26 AM
re: Web Encryption That Works
Businesses need to think carefully about the cipher technologies
they're using with the SSL protocol that do the actual encrypting
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-3861
Published: 2014-09-02
Cross-site scripting (XSS) vulnerability in CDA.xsl in HL7 C-CDA 1.1 and earlier allows remote attackers to inject arbitrary web script or HTML via a crafted reference element within a nonXMLBody element.

CVE-2014-3862
Published: 2014-09-02
CDA.xsl in HL7 C-CDA 1.1 and earlier allows remote attackers to discover potentially sensitive URLs via a crafted reference element that triggers creation of an IMG element with an arbitrary URL in its SRC attribute, leading to information disclosure in a Referer log.

CVE-2014-5076
Published: 2014-09-02
The La Banque Postale application before 3.2.6 for Android does not prevent the launching of an activity by a component of another application, which allows attackers to obtain sensitive cached banking information via crafted intents, as demonstrated by the drozer framework.

CVE-2014-5452
Published: 2014-09-02
CDA.xsl in HL7 C-CDA 1.1 and earlier does not anticipate the possibility of invalid C-CDA documents with crafted XML attributes, which allows remote attackers to conduct XSS attacks via a document containing a table that is improperly handled during unrestricted xsl:copy operations.

CVE-2014-6041
Published: 2014-09-02
The Android Browser application 4.2.1 on Android allows remote attackers to bypass the Same Origin Policy via a crafted attribute containing a \u0000 character, as demonstrated by an onclick="window.open('\u0000javascript: sequence.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
This episode of Dark Reading Radio looks at infosec security from the big enterprise POV with interviews featuring Ron Plesco, Cyber Investigations, Intelligence & Analytics at KPMG; and Chris Inglis & Chris Bell of Securonix.