Tackling SSL vulnerabilities for secure online transactions

A rash of CA breaches shows up weaknesses in the SSL infrastructure. Take action to protect your customers and employees.

IMS February 2012 Issue

Despite the economic gloom, business is booming on the Internet. An IBM study of 500 retailers reported that online Black Friday sales were up 24.3 percent year-over-year, while according to statistics from U.K.-based online retail software company MetaPack, online sales in December were up 30 percent and the last week before Christmas saw almost double the sales compared with last year. Critical to this success and the ongoing viability of any kind of Internet business is the ability of customers to complete secure transactions online. Whether it’s a financial transaction or logging into an online account, users need to be able to verify who they are communicating with and know that the contents of that communication are safe.

However, a number of attacks on high-profile certificate authorities last year have highlighted the fallibility of Web server certificates, while the security of Secure Sockets Layer (SSL), the protocol behind secure online transactions, has been called into question. In this article, we’ll examine the infrastructure for online transaction integrity, take a look at recent CA compromises and research into SSL vulnerabilities, and outline countermeasures for ensuring Web security for your customers and employees.

The online trust infrastructure
SSL and its successor, Transport Layer Security (TLS), still generally referred to as SSL, are the protocols behind secure online transactions. SSL uses public key encryption (PKI) to encrypt the data sent between a user’s browser and a website. This prevents anyone from eavesdropping or tampering with the data, while the Web server’s digital certificate allows any user to verify the owner of the site and that the page they're viewing is actually coming from the site they intended to visit. The secure lock symbol displayed by most browsers when a page is delivered via SSL allows the user to view the SSL certificate and see the certificate owner’s name and the certificate authority (CA) who issued it.

Until a few years ago, SSL was mainly used by sites handling financial transactions such as banks and ecommerce sites like eBay and Amazon. Also, many of these sites only used SSL for pages containing sensitive information such as login credentials or payment card details, but there is now a growing trend towards moving entire sites to Hypertext Transfer Protocol Secure (HTTPS), a combination of HTTP with SSL where all content in the page is delivered via SSL. Google has announced plans to make SSL encryption the default for its online applications and PayPal is already an HTTPS-only website. It’s ironic then that last year several major CAs, a lynch pin in the entire PKI chain of trust, were compromised.

Information sent via SSL to a website is encrypted using the Web server's public encryption key and the server uses its private key to decrypt it. This is called a key pair. As anyone can build a website and create a key pair, a mechanism is needed to enable visitors to the site to securely check that the site’s public key truly belongs to the stated owner. This is where digital certificates and certificate authorities (CA) come in. The primary role of a CA is to be an independent and mutually trusted third party that checks the credentials of an organization to ensure it actually operates a particular site.

The CA then creates a digital certificate that contains information such as the organization’s name, location, serial number, public key and expiration date. It binds the site’s public key to the organization’s website address by digitally signing the certificate using its own private key. When a Web browser makes a secure connection to the site, its digital certificate is automatically checked for anomalies or problems, and alerts the user if any are found. If everything is in order, the browser completes the secure connection. This process happens entirely behind the scenes between a Web browser and a website, so Web users are unaware of it unless there's a problem with the digital certificate. In those cases, a Web user will typically receive a warning message about a potential security problem with the website they're trying to visit.

A frail foundation
As you can see, a CA provides assurance that a website is legitimate, so confidence in the website’s certificate relies on trust in the CA. Alarmingly, more than 500 bogus certificates are thought to have been issued for a range of sites, including Google and the CIA, using the now defunct CA DigiNotar’s key. Also, an affiliate of CA Comodo was compromised, resulting in the fraudulent issuance of certificates for Google, Yahoo, Skype, and Microsoft, and GlobalSign temporarily stopped issuing digital certificates after hackers claimed to have accessed its network. According to research from the Electronic Frontier Foundation, at least four of the more than 600 certificate authorities were compromised in the second half of 2011.

With a forged certificate, a hacker can easily dupe a visitor into believing that they have reached one of these sites. The padlock would show in the address bar and a valid certificate would appear if checked, giving the user no indication that the website was anything but secure and legitimate. Until the certificate is revoked and the browser’s certificate list is updated by the vendor, users are at risk. Mobile phone users are at even greater risk; security updates are generally not released as quickly as for desktops and it’s almost impossible to remove digital certificates from a mobile phone.

To protect users against the risk of fraudulent DigiNotar SSL certificates, all major browsers have implemented changes so they no longer trust certificates issued by DigiNotar. However, this required each browser manufacturer to push updates to their browsers. The move to silent updates for browsers does mean more users will be surfing using the latest versions, but there is currently no method for browsers being able to reference a single master list. This approach would help stop the compromise of a major CA that could lead to widespread mistrust across the Internet. Browsers don’t need to trust all 600 plus CAs all of the time, but a master list would make this task easier. (Online Certificate Status Protocol stapling, a time-stamped validation of a digital certificate, is a step in the right direction, but the entire CA industry needs overhauling.)

However, SSL-based Web transactions are not just being threatened by the integrity of Web server certificates; the SSL/TLS protocols are under attack. Researchers recently demonstrated an attack that decrypted an active HTTPS session between the PayPal website and a browser. The attack tool, called BEAST (Browser Exploit Against SSL/TLS), uses JavaScript to exploit a flaw present in SSL 3.0/TLS 1.0, the default protocol setting in most browsers as servers around the world are yet to fully implement TLS1.1. While the possibility of a successful attack in the wild is slim, this particular attack against SSL creates further uncertainty; fixing the problem of compromised CAs may require a new trust model, but fixing this vulnerability will probably require a major change to the SSL protocols. This is a real problem as any fix is unlikely to be compatible with many existing SSL applications.

The above attack, like many others, requires the attacker to inject malicious code and run it within the user's browser session so it is treated as from the same origin as the HTTPS server. This makes secure Web application development more important than ever. You should ensure all non-static data is validated before it is processed by any Web server application or script. This requires, for example, checking where your code expects an input to be an integer that it is indeed an integer. To do this effectively you need to declare and use the same HTML encoding throughout your site and scripts. This prevents attackers from slipping through filters by encoding characters using a different character set.

Reducing web security risks
Site administrators using a Web server certificate should check that it has correctly installed and the site is configured to make maximum use of it. Many CAs have recently increased the key size of their signing certificate and some default server installs do not have the updated bundle of chained certificates necessary for all browsers to recognize the server’s certificate without complaint. You can easily check your own installation by using GeoCerts SSL Checker. You should only use a Web server certificate with a minimum key length of 1024 bits.

Next, ensure all contents of your pages are fetched via HTTPS. Often some media elements, such as style sheets and JavaScript are fetched via HTTP. This creates a situation where although the main page load is protected against active and passive network attacks, none of the other resources are, leaving the user exposed. Also set the Scope and Secure attributes of any cookies to prevent them from being sent to a non-HTTPS page. Moving your entire site to HTTPS is not that difficult. You can redirect all HTTP requests with HTTP 301 or 302 responses to the equivalent HTTPS resource. Also, Google and Mozilla browsers support the HTTP Strict Transport Security (HSTS) protocol extension that instructs browsers to expect the site to use HTTPS.

A website administrator  may be concerned about the effects SSL has on the speed at which visitors get to see the contents of their site. The encryption process slows down the delivery of a site’s pages and Google hasn’t extended SSL across all its services yet, as they want to test the effects on performance. SSL involves a trade off: improved security versus slower response times. The impact on performance  is one reason why SSL isn’t the default for connecting to websites.

Interestingly, Google is finding that SSL is not the CPU hog that many believe, so this shouldn’t be grounds for stopping organizations from moving towards HTTPS-only. Run some tests, though, prior to making the transition, as most browsers don’t cache documents delivered over SSL. This will generate extra Internet traffic and a greater number of page requests for your Web server to process, as browsers will make a fresh request each time the page is viewed instead of pulling it from its cache.

Organizations should also consider implementing a Content Security Policy, which requires configuring a Web server to return the X-Content-Security-Policy HTTP header to specify a website’s policy. This is a string containing policy directives to indicate the class of content that is to be restricted by the browser and the range of permitted behavior for that content class. Typically this is a location, such as a network host, which is permitted to serve content of a particular type.

Although the Content Security Policy specification is only a public working draft, it’s likely to become a World Wide Web Consortium (W3C) recommendation as it prevents webpages from displaying content from unauthorized locations. It also mitigates clickjacking, where a malicious site directs a victim's mouse click to another site, and packet sniffing attacks. There are already experimental implementations in Firefox, Chrome, and IE 10, and a Content Security Policy is fully backwards compatible so users reaching a website  with a browser that doesn’t support it will simply disregard the CSP header.

Other tweaks organizations should consider making to their  server include enabling TLS 1.1 and/or 1.2 and prioritizing the RC4 algorithm since the latest versions of the TLS protocol are not vulnerable to the BEAST. (If a browser doesn’t support RC4 it will just use a different cipher.) Another best practice for sites that process high-value transactions or are likely to be a target of sophisticated attacks is to implement transaction signing so an attacker can’t inject bogus data. This type of out-of-band authentication, using a hardware token or mobile phone, is robust against man-in-the-middle attacks, cannot be replayed, and has strong non-repudiation properties as the user has to enter the correct transaction details; any other transaction will fail to produce a valid response. To improve the security of employees while they surf the Web, companies should also change the default protocol version for HTTPS requests to be used by their browser to TLS 1.1 and prioritize the RC4 algorithm for secure communication.

SSL is still the best method we have for providing authentication and encryption between a server and a client, but as always, site administrators need to keep abreast of new attack vectors and developments by vendors to combat them. Properly configuring your site to make the most of SSL greatly improves its security and that of the people who use it. The more secure we can make the Internet, the better off we’ll all be.

About the author:
Michael Cobb, CISSP-ISSAP, has more than 15 years of experience in the IT industry and another 16 years of experience in finance. He is the founder and managing director of Cobweb Applications, a consultancy that helps companies to secure their networks and websites, and also helps them achieve ISO 27001 certification. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Send comments on this article to [email protected].

Dig Deeper on Web application and API security best practices