Secure online X-mas shopping? Big stores encrypt, the corner-store doesn’t

Encryption usage by Norwegian online shopping sites (2016 edition)

Over the past several years I have performed occasional surveys of Norwegian shopping sites and their use of encryption. I decided to limit my surveys to Norway, because I concluded that limited knowledge would make collecting a representative international list of foreign shopping sites difficult, and would probably only contain large stores, not small ones.

The last survey I wrote about was performed in early 2015, and while I did not publish an article about it, I did perform a second survey a few months later, in order to get an impression of the effects of some actions initiated after my article. The changes at the time were not significant enough to change what I presented in the previous article, so I did not publish an article discussing those updated results. Continue reading “Secure online X-mas shopping? Big stores encrypt, the corner-store doesn’t”

There are more POODLEs in the forest

In December it was announced that several TLS server implementations were affected by a problem similar to an SSL v3 issue called POODLE disclosed by Google researchers in October. This attack worked by modifying the padding bytes of the encrypted SSL/TLS records that are used to make the records into even multiples of 8 or 16 byte blocks of data, checking how the server responded, and used this to deduce the plain text of the transmitted data, one byte at a time, with just a few tries.

Several major vendors were affected by the TLS variant of the POODLE issue, and released patches. Continue reading “There are more POODLEs in the forest”

The POODLE has friends

In October last year, researchers from Google published details about an attack on SSL v3, called POODLE. This attack worked by modifying the padding bytes of the encrypted SSL records that are used to make the records into even multiples of 8 or 16 byte blocks of data, as used by 3DES and AES encryption in the “CBC” mode, checking how the server responded, and used this to deduce the plain text of the transmitted data, one byte at a time, with just a few tries. Continue reading “The POODLE has friends”

Usikker registrering av persondata i mange nettbutikker

[Apologies to my English language readers, as this article mainly concerns encryption in Norwegian online shopping sites, I decided to write it in Norwegian]

Jeg har ved at par tidligere anledninger undersøkt bruken av kryptering av norske nettbutikker, sist i 2013. Konklusjonen begge ganger har vært at kryptering er lite brukt.

I løpet av januar gjennomførte jeg en ny undersøkelse av kryptering i norske nettbutikker. I tillegg til 59 butikker jeg hadde undersøkt tidligere, inkluderte jeg denne gangen 184 nye nettbutikker fra Posten.no‘s liste over nettbutikker, totalt 243 butikker.  Continue reading “Usikker registrering av persondata i mange nettbutikker”

Not out of the woods yet: There are more POODLEs

As I wrote in my previous article about this, in October a group of Google security researchers had discovered a problem, called POODLE, in SSL v3 that in combination with another issue, browsers’ automatic fallback to older TLS and SSL versions, allowed an attacker to quickly break the encryption of sensitive content, like cookies.

The main mitigating methods for this problem are disabling SSL v3 support, both server side (now down to 66.2%, but slowing down) and in the client, and to limit the automatic fallback, either by not falling back to SSL v3 (which is now implemented by several browsers), or by a new method called TLS_FALLBACK_SCSV (introduced by Google Chrome and others). Continue reading “Not out of the woods yet: There are more POODLEs”

Attack of the POODLEs

Three weeks ago a group of researchers from Google announced an attack against the SSL v3 protocol (the ancestor of the TLS 1.x protocol) called POODLE (a stylish abbreviation of “Padding Oracle On Downgraded Legacy Encryption”). This attack is similar to the BEAST attack that was revealed a few years ago, and one of the researchers that found the POODLE attack was part of the team that found BEAST.

POODLE is able to quickly discover the content of a HTTPS request, such as a session cookie, but only if the connection is using the SSL v3 protocol, a version of SSL/TLS that became obsolete with the introduction of TLS 1.0 in 1999. As almost all (>99%) secure web servers now support at least TLS 1.0 (which is not vulnerable to the attack, provided the server is correctly implemented), it might sound like this attack is not very useful. Unfortunately, that is not so. Continue reading “Attack of the POODLEs”

The Heartbleed vulnerability (or why you should change your Vivaldi.net password)

A few days ago a group of researchers revealed that they had discovered a serious vulnerability in OpenSSL 1.0.1, an implementation of the Transport Layer Security protocol (TLS, or SSL) which they called “Heartbleed“.

This vulnerability is very serious and will take its place among other serious TLS-related vulnerabilities of the past few years, such as the Renego problem, BEAST, CRIME and others, and is probably even more severe than any of them, particularly since this problem does not require working with a complex setup through the user’s browser, and the scope of the attack affect all users, not specific users. Some, like Bruce Schneier, are using the word “catastrophic” and this label may actually be warranted in this case.

Heartbleed’s severity is due to the fact that an attacker, exploiting a problem in OpenSSL’s implementation of a TLS protocol feature called the Heartbeat extension, developed as a lightweight way to check if a secure server is still alive, can get 64 KB of raw memory from the vulnerable server. This memory can contain passwords, or other sensitive user data, but worst of all: it can contain the private encryption keys used to secure all transactions with the server, meaning that an attacker can pretend to be the site and perform a Man In the Middle attack against the site and its users. The problem have been present in OpenSSL for two years, and there is no way to know if it have previously been discovered and used by others.

Consequences

There have been a lot of writing in various news sites about this issue, and while some have moderated their stories after a while, many still have some exaggerations as well as some very bad advice mixed with good advice.

First of all, this issue does not affect 65-70% of all websites, 17% is probably more accurate. It is accurate that about 65-70% of web sites use OpenSSL, but most are still using older versions that are not vulnerable to this issue. Netcraft estimates the number of affected servers at 17%. This sounds reasonable, as my own scans indicates that 23% of TLS servers that I have scanned
support TLS 1.2, not all of which are using OpenSSL, which was also added in the vulnerable versions of OpenSSL.

As the vulnerability also may have exposed user’s passwords, a number of articles recommends changing passwords, in part prompted by statements from computer security experts and government agencies, some of them saying something like “Change all your passwords RIGHT NOW!!!”. Unfortunately, if you do so without doing a couple of checks first, that could be almost the worst thing you can do. Why? This is why: if the website has not been updated and secured before you change the password, then you might just be handing the attackers your new password on a silver platter. Before changing your password, make sure, by asking them, that the site have secured its servers. Otherwise, you may have changed one unsecure password for another one, and will have to repeat the process when the site have been secured.

Also, please note that some websites may send emails about this issue, and that scammers are sure to follow up with phishing email  using Hearthbleed password updates as the bait. Never click on links in such emails! Use your normal URL for accessing the site, verify that the site has been secured (by asking), then change the password using the standard methods for doing that, in the account preferences.

What about Vivaldi.net?

Like many sites with a modern Linux based server park, Vivaldi.net was using one of the vulnerable versions of OpenSSL, as was our distribution service, CloudFlare.

To fix the problem on our servers, we did not just have to upgrade the servers to use the patched version, we also had to create new private encryption keys for our servers and obtain new SSL/TLS certificates for them, and revoke the old certificates. Our servers are now secure against this problem.

We, and all other web sites affected by the problem, have to go that far, since the vulnerability may have exposed our private keys, which means they cannot be trusted anymore.

However, be aware there may be a couple of side effects for clients due to the changed certificates. When we changed the certificates we also upgraded them to being signed by the more secure SHA-256 method. This also means that the certificates are signed by a new intermediate certificate, but the web and email servers are sending this certificate, but it appears that some clients have problems, either with the certificates or by not understanding SHA-256. In such cases an upgrade of the client may be necessary.

Unfortunately, the process of recovering from this vulnerability is not over yet. Now it is your turn.

We do not know, and probably will never know, whether or not somebody attacked our servers using this vulnerability before we were able to patch the servers and replace the certificates. If they did, then the passwords of all our users may have been compromised, and this means that you should change your password for Vivaldi.net as soon as possible.

The state of encryption usage in online shopping

 

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.

Dårlig bruk av kryptering i norske nettbutikker

 

[To those of my readers who understand English, but not Norwegian: This article is written in Norwegian because it is about the use (or lack) of encryption in Norwegian online shopping sites. A larger article about this topic is planned.]

Bladet Dine Penger‘s nettavis publiserte 28. Februar resultatene av en test av prisnivået på elektronikk i norske nettbutikker, gjennomført av Hardware.no.

Som artikkelen helt korrekt peker på, er prisnivå bare et av aspektene man bør vurdere når man skal velge nettbutikk, noen vil for eksempel vektlegge servicenivået i butikken, og personlig så ser jeg også på hvordan nettstedet bruker sikkerhetsteknologi, spesielt kryptering, som kan måles fra nettleseren.

Det er, som jeg har nevnt tidligere, svært vanskelig å finne ut om en nettbutikk håndterer kundens informasjon på en tilfredsstillende sikker måte. Årsaken er at dette avhenger av faktorer som ikke er synlige for kundene, og som, av forretningshensyn, blir holdt hemmelig. Kundens første indikasjon på at noe er galt kan være et oppslag i pressen om at “Butikk X mistet N tusen kunders informasjon”, og da er det for sent å gjøre noe. I et forsøk på å styre klar av slike problemer må kundene da basere seg på andre faktorer, inkludert butikkens gode (eller dårlige) rykte, uavhengige inspeksjoner av butikkens systemer, og/eller andre ting som kunden kan observere, for eksempel hvor god butikkens bruk av kryptering er.

Hvor godt et nettsted bruker kryptering er i det minste en indikasjon på hvor godt nettstedet ellers sikrer kundens personlige informasjon, selv om det ikke nødvendigvis er en direkte sammenheng. Imidlertid vil jeg påstå at manglende eller dårlig bruk av kryptering av viktige oppgaver som kunderegistrering, innlogging og “gå til kassen” er en god indikasjon på manglende omtanke for kundens sikkerhet.

I denne forbindelse definerer jeg “Ingen kryptering” som at de nevnte aktivitetene blir startet på en ukryptert side, eller en side som blander kryptert og ukryptert innhold. Et eksempel er innlogging som gjøres direkte fra en ukryptert forside, selv om innloggings-detaljene sendes kryptert. Dersom kryptering ikke brukes for disse aktivitetene vil en angriper kunne stjele kundens informasjon uten at det er mulig å oppdage det. Et slikt angrep kan for eksempel skje ved at brukeren blir lurt til å koble seg til en kompromittert Wi-Fi hotspot.

Om en nettside bruker kryptering er enkelt å finne ut av, ved å se på nettleserens indikasjon av om siden er sikker, vanligvis omtalt som “hengelåsen”, selv om den ikke lenger nødvendigvis ser ut som en hengelås i de forskjellige nettleserene, og for nettsteder med spesielle sertifikater (som blant annet brukes av banker) vises “hengelåsen” på en grønn bakgrunn. Mer informasjon om dette finnes i min artikkel om norske nettbutikker fra i fjor.

I forbindelse med de nettbutikkene som ble testet av Hardware.no, så viser en undersøkelse jeg har gjennomført av disse nettbutikkene (riktignok uten å gjennomføre betaling eller innlogging) at bare 41% av nettstedene benyttet kryptering for kunderegistrering, innlogging og “gå til kassen”. Resten (59%) brukte enten ikke kryptering i det hele tatt (35%), eller brukte bare kryptering for noen av aktivitetene (24%), ofte bare “gå til kassen”.

Med andre ord: De fleste av de nettbutikkene som er presentert av Dine Penger og Hardware.no bruker ikke god kryptering, og er derfor ikke særlig sikre.

Det er imidlertid noen lyspunkt: Amentio, Deal.no, og Mamoz bruker kryptering i hele nettbutikken.

Det er sikkert også noen som vil spørre “er kryptering så viktig da?” Kryptering hindrer angripere fra å stjele informasjon, f.eks. passord (som ofte er gjenbrukt på flere nettsteder, selv om dette er frarådet av alle sikkerhetseksperter), direkte fra nettforbindelsen, og avhengig av nettbutikken kan dette også gi adgang til sensitiv informasjon, f.eks. kredittkortinformasjon. Av juridisk interesse for nettbutikkene så er det mulig at manglende kryptering er et brudd på norsk personvernlovgivning. Så: Ja, korrekt bruk av kryptering er viktig.

For å bedre illustrere hvor god bruken av kryptering er i en nettbutikk, har jeg lagd en enkel karakterskala, fra “A” (best) til “F” (dårligst).

Denne karakterskalaen er basert på hvordan kryptering brukes, og i tillegg hvordan de har håndtert noen andre problem områder: 1) hvorvidt nettbutikken har fikset et 3 år gammelt, velkjent sikkerhetshull som kalles “Renego-angrepet“(CVE-2009-3555), eller 2) er sårbar for dette angrepet, og 3) om nettstedet støtter usikker kryptering som gikk ut på dato i år 2000 eller tidligere.

Med denne skalaen blir butikkene i Hardware.no’s test rangert som følger:

A: Hele butikken kryptert, Renego fikset, ingen støtte for svak kryptering

B: Hele butikken kryptert, Renego fikset

C: Kryptering for registrering, innlogging og kasse, Renego fikset

  • MPX.no
  • Komplett.no
  • Netshop.no
  • Expert.no
  • Maxfps.no
  • KomplettHome

D: Kryptering for registrering, innlogging og kasse, Renego ikke fikset, men tilsynelatende ikke sårbar for angrep

  • CDon.no
  • Amentio.no
  • Deal.no
  • Mamoz.no
  • Apple

E: Kryptering for maks 2 av registrering, innlogging og kasse, tilsynelatende ikke sårbar for Renego angrepet

  • NetOnNet
  • Dustinhome
  • FotoVideo
  • Expansys

F: Mangler kryptering, eller bruker sårbar blanding av kryptert og ukryptert innhold (dvs. en angriper kan ta full kontroll over et nettsted uten å bryte krypteringen), eller er sårbar for Renego angrepet.

  • PixMania
  • Siba
  • Lefdal
  • ProShop.no
  • Atea Direct
  • Elkjop.no
  • Multicom.no
  • Supersmart.no
  • Digital Impuls
  • Dataspesialisten
  • StartIT
  • SesamData
  • ilb.no
  • Yaha.no
  • it24.no
  • Japan Photo
  • Iwill Norge AS
  • Teknikmagasinet
  • Euronics.no

Min anbefaling er at kundene bør ikke velge nettbutikker som har fått karakteren “E” eller “F”, inntil de har fikset problemene de har med manglende eller dårlig kryptering, og dermed fått en bedre karakter.

Hva bør kundene gjøre?

Kundene bør først og fremst lære seg hvordan nettleseren deres viser at et nettsted bruker kryptering(“hengelåsen”), eksempler finnes i min artikkel <>, og man kan selv teste dette ved å gå til Facebook (vanlig hengelås) og Paypal (grønt felt).

Deretter må kundene bli vant til å sjekke hengelåsen før de oppgir brukernavn, passord, andre personalia, og kredittkort informasjon. Hvis de ikke ser hengelåsen når nettstedet ber om slik informasjon, så må de avbryte handelen og gå til en annen butikk.

[Oppdatering 10. April: Mer testing av Netshop.no viste at selv om forsiden er kryptert, og linker til varer og menyer bruker HTTPS, blir disse redirigert til ukryptert HTTP. Dette ble desverre ikke oppdaget under testingen. Karakteren for Netshop.no er derfor endret til C]