Last year I wrote about how Norwegian online shopping sites seemed to be using less encryption than international online shopping sites.
As I said in that article, given that it is difficult or impossible for a customer to discover how well an online shopping site will protect your information and privacy, proper use of encryption is one of the few indicators available to customer of how seriously the shopping site take their customer’s security and privacy.
Unfortunately, all-encryption is not a full-fledged, perfect indication of good security; a shiny exterior can still hide a fairly insecure system, in which case the first indication a customer might have that something is wrong will be big headlines in newspapers about how a “big site lost X million passwords and personal details to attackers”, at which time it is too late to do anything.
On the other hand, lack of proper use of encryption is a definite indication that the site does not take your security and privacy seriously, because, as secure as the system might be under the hood, if encryption is not properly used to secure access to the site, none of that security will matter since the front-door will be wide open to the attackers.
This year I have repeated the survey, increasing the number of sites to 68 Norwegian and 68 international sites. In both categories the majority of the sites are from big brands in their national markets. Most of the international sites are American, but there are number of European sites, as well.
As part of the survey, I checked the following:
Was encryption used properly for customer registration, login and checkout?
I define “Proper use of encryption” as follows: the entire login process was performed on a page loaded completely from a secure server. For example, submitting the details “securely” from an unencrypted page, or opening a “secure” frame/pop-up inside an unsecure page cannot be considered proper use of encryption. There were a few cases that used some kind of (probably JavaScript) redirection that caused Opera to show such pages as unsecure before I manually reloaded the page, which after giving the issue some consideration I decided to classify as secure. Please note that I did not check the payment systems or post-login systems of any of these sites.
Is the entire shopping site encrypted?
This can actually be rather difficult to determine accurately, since there can be localized bugs or configuration issues that causes the website leave the secure area. I have noticed this in at least two cases that I have investigated recently.
Is the server patched for the so-called “Renego” (CVE-2009-3555) issue?
If it is not patched, is it definitely vulnerable to the full Renego attack, or not? As readers who follow my articles will know, I have been following this topic for the past three years, since it was discovered, and been using the TLS Prober to track the patch coverage. If the server is fully vulnerable to this issue, an attacker can trick the server into performing actions using the user’s credentials (an early proof of concept was to make the user post his twitter password to the twitter stream), and even if the server is not obviously vulnerable, there might be special circumstances under which it could become vulnerable, which is why the issue must be patched completely, not just pseudo-patched with a temporary workaround.
In this survey the Norwegian Renego patch coverage is markedly lower than in the international shops, only 52% were patched, compared to 77% in the international sites and 75% in the general population (as of December 2012). At present, in general a rather high fraction (57%) of the unpatched sites are also vulnerable to the Renego attack, and the number of unpatched and vulnerable sites in this survey are not very different from that number.
Does the server support SSL v2 and/or 40/56 bit “US-exportable” encryption?
While modern browsers do not support any of these methods (SSL v2 was replaced by SSL v3 in 1996, “exportable” encryption became demonstrably unsecure in early 1999), there is an extensive number of servers that are configured to use them, even if it is no longer needed. The only “real” scenario where support for these could be of use, is if your site is catering to users of Netscape 1 and MSIE 2 (SSLv2) or the international versions of Netscape 4 and MSIE 4 (weak crypto), and I seriously doubt that anyone are really doing that, considering all the concern about “having” to support much more recent browser versions. Even though these methods are not supported by modern versions of browsers, older versions of the browsers (e.g Opera 7) with support enabled, might still be in use, and if so, these old methods are so weak that it is reasonable to assume that than an attacker can easily downgrade the security of connection so that it will use the weaker methods.
There was a marked difference in this area between the Norwegian sites and the international sites, with a much higher number of Norwegian sites (46%) supporting SSL v2 than among the international sites (13%), and in fact the Norwegian count was slightly higher than the general support of SSL v2 (40%).
For weak crypto the differences were less marked, with Norwegians at 36%, internationals at 29%, both much lower than the general support of 47%. However, when combining the numbers for sites with weak crypto and/or SSL v2, there is a very large difference between the Norwegian sites (54%) and international sites (30%), both below the general support of 65%.
Website grading system
As there are many components of such a survey, to make evaluation of all the security aspects easier I have developed an A-F grading system for how sites use encryption. This system was first used in my Norwegian article two weeks ago.
The grades are defined as follows:
A: The entire shop is encrypted, Renego patched, no weak encryption.
B: The entire shop is encrypted, Renego patched
C: All of registration, login and checkout are encrypted, Renego patched
D: All of registration, login and checkout are encrypted, not vulnerable to the Renego attack
E: At least one of registration, login and checkout are encrypted, not vulnerable to the Renego attack
F: No encryption, or vulnerable use of resources, or Renego vulnerable.
A B C D E F C+D E+F
Norwegian 0,0% 1,5% 16,2% 11,8% 10,3% 60,3% 27,9% 70,6%
International 0,0% 0,0% 38,2% 7,4% 25,0% 29,4% 45,6% 54,4%
As can be seen from the table above, and the graph, there is a huge difference between the Norwegian sites and the international sites concerning how well they use encryption, with far fewer Norwegian than international sites using encryption properly, and far more using encryption improperly.
However, while the number of Norwegian sites with complete lack of proper encryption was much higher than for the international sites, in one area the Norwegian sites seems to be a step ahead of the their international competitors: Five of the sites were using encryption for the entire site, although most of them unfortunately came up short for one or more of the other points I was considering when grading sites (usually Renego), and ended up with a “D”-grade, or lower.
However, even though the international sites’ usage of encryption is better than the Norwegian sites’ usage, there is still a very large segment of international sites (54%) that uses encryption improperly, so it might be useful to look at these in more detail:
- Almost half of those (rated E, 25% of total) are using encryption properly for only one or two of the three main tasks that have to be secured.
- Among the sites rated F (29% of total), 45% were Renego vulnerable, 70% were using no encryption or improper encryption. The corresponding numbers for Norwegian sites were 29% and 73%.
These numbers indicate that while a lot of Norwegian sites need to significantly improve their use of encryption, there are many international sites that have to do so, as well.
A big question raised by this information is why are so many shopping sites using poor encryption? The answer will likely vary between sites, and what they tried to do, but here are some guesses:
Sites that use no encryption for some or all of the tasks
Didn’t think of it
Don’t need encryption
At least here in Europe these sites may actually be skirting the law, if not actually breaking it. In Norway the laws protecting personal information require encryption whenever “protection-worthy” personal information is being processed, which should definitely include purchasing history and payment details.
Concerned about performance
If it ever was a valid issue, the SSL/TLS performance concern has long since been debunked for properly configured systems. When Google moved GMail entirely over to HTTPS Google reported that they did not deploy any new servers, and that the HTTPS related activity was less than 1% of the CPU load on the servers.
Sites that use encryption submitting the information, but not for the page with the form
But, but, … The information is sent securely!
If the page collecting the information is not encrypted, it does not matter at all if the password or payment information is sent securely, because the lack of encryption gives the attacker free hands change the page so that it also sends the collected information to the attacker before it is sent to the website.
Sites that use secure pop-ups for entering the information, on an unsecure page
The pop-up frame is secure, and it protects your information
Unfortunately, that is not true, because the user cannot tell that the frame is secure. Just like in the case above, as long as the containing page is unencrypted, the attacker can make the page do anything needed to obtain a copy of the submitted information, including replacing the “secure” frame with his own hijacked variation that will forward a copy of the information to the attacker.
Sites that use secure pages, but security is compromised by mixed content
Ooops! Sorry! Will fix it. <Sound of feet running in the direction of the web server>
In many of the cases when pages use mixed encryption, the cause of the problem turns out to be third-party resources, advertisements and APIs, in particular external JavaScript APIs (which compromises the page’s security completely). Whether true, or not, it often seems as if the third-party code have previously been used on unsecure pages and just copied to the secure pages, thus breaking their security. The vendors of such JavaScript APIs need to update their instructions, and change the recipes so that the website administrator never specify the protocol to use, and making the URLs look like this: “//www.example.com/scripturl.js”. This is supported by all modern browsers and will automatically create a http URL when the containing page is served over HTTP, and a https URL when it is served over HTTPS.
Other causes
Of course, the is one other possible reason for this state of affairs: The customers, in large parts, let the online stores get away with not protecting their security and personal information. One can argue endlessly about whether this is caused by lack of knowledge about the risks, not caring at all, or that they just want to complete the transaction immediately, or if it is caused by any number of other reasons.
There is only one countermeasure for this kind of problem: Raising awareness, both to educate customers, and to point out to the online stores that they need to improve their security. One such initiative is x509labs, but the best signal to the stores require customers to start taking their own security and privacy seriously, and vote with their wallets.
