Vivaldi.net now showing EV-green in browsers

Friday evening (20 December) those who keep an eye on the browser UI would have observed a small but significant change take effect at Vivaldi.net: The browser turned on the Extended Validation “Green Bar” for us, indicating that the identity of our website was now better assured than it has been, though the encryption is just as good as before.

Previously, while we were developing the site and during the first days of it being live, we used a Domain Validated SSL/TLS certificate for our sites that indicated that we had control over the domain, but not who we are. This is a useful level of web site identity verification for smaller sites that only need to present information securely and without any major collection of personal information. 

For users of a web site that collects or manages personal and payment information, it is not just important to know that the people managing the web site are in control of the domain. It is even more important to know, or be able find out, who they are, legally speaking, in case there is a problem.

This need for verifiable identity information was why a group of Certificate Authorities, such as Verisign and Entrust, and Browsers, such as Microsoft, Mozilla and Opera (including yours truly), gathered to found the CA/Browser Forum so that we could define what eventually became the Extended Validation (EV) Guidelines for CAs, and the associated “Green Bar” in browsers.

When Jon decided to start the Vivaldi.net social web site project, one of my suggestions was to have an encrypted site. Given recent revelations (e.g., NSA) it is now, or should be, unthinkable to have a social web site that is unencrypted. While many sites have been using a hybrid approach where the login, account management, and sometimes authoring, is encrypted, there are just too many ways to sniff information that way, so the whole site needs to be encrypted. Another of my suggestions was to use EV certificates on the sites, to provide better identity information and assurances to our users.

While I would have wished to have unveiled Vivaldi.net on Wednesday with an EV certificate, the process of obtaining one was intentionally designed to include a lot of paperwork that has to be completed before the certificate can be issued, and that paperwork was not completed by our CA, GlobalSign, until early evening Friday.

So, go ahead and enjoy Vivaldi.net, assured that it is Jon’s company, Vivaldi Technologies AS, that is operating it.

I’m still a techie, not a nettie

Welcome to a my new home on the Web.

After I left Opera a year ago, I considered moving my (old) home page to a new location, but did not find a good location to host it.

Moving to a new location became a bit more urgent when Opera announced their decision to  shut down MyOpera in a couple of months.

Fortunately, my new old boss, Jon von Tetzchner, decided that with MyOpera shutting down, he would provide a new home for all the people made “homeless” by the shutdown. The new site, Vivaldi.net, went live as a  beta version yesterday, and I have now started the migration here.

The small print: Opinions stated here are my own, and do not necessarily represent my employer’s views. Opinions are subject to change without notice, in particular when I find (or am pointed to) better information, unless I decide to be stubborn. Articles may contain spelling mitsakes, errors grammatical, or other mistakes; in such cases the correct meaning is what I meant to write, not what is in the text; when in doubt, ask.

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]