Last week, news arrived about a new vulnerability in OpenSSL, which affected all releases of the library. This new vulnerability, frequently referred to as the CCS vulnerability, is a Man In the Middle (MITM) vulnerability, allowing an attacker to listen in on, or modify data on a connection by tricking the client and server to set up their connection using predictable encryption keys. Continue reading “The OpenSSL CCS vulnerability”
(Update: A number of references to this article have incorrectly referred to me a working for Opera Software. Please note that I left Opera Software more than a year ago, and that I now work for Vivaldi Technologies AS)
Update May 12: After closer investigation together with F5, it seems that, due to an issue with the network connection of the prober the test used to detect F5 BigIP server showed higher numbers than it should have, and the numbers of such servers therefore got very inflated for the scans that were run in the past month. This means that the BigIP related information and conclusions are not correct, and I have therefore moved down and struck out the section regarding BigIP servers. My apologies to F5 and their customers for this mistake. Continue reading “Heartbleed Status: Upgrading to Heartbreak”
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.
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.
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.
Welcome to a my new home on the Web.
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.
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?
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.
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>
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.
[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.]
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
D: Kryptering for registrering, innlogging og kasse, Renego ikke fikset, men tilsynelatende ikke sårbar for angrep
E: Kryptering for maks 2 av registrering, innlogging og kasse, tilsynelatende ikke sårbar for Renego angrepet
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.
- Atea Direct
- Digital Impuls
- Japan Photo
- Iwill Norge AS
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]