Implementer's notes

[To those of my readers who understand English, but not Norwegian: This article is written in Norwegian because it is about the use of encryption in Norwegian online shopping sites. I may post an English version later]

Handel på nett utgjør en stadig større del av norsk handel, og ble ifjor estimert til 48 milliarder kroner av DIBS, ifølge en artikkel på Digi.no/NTB.

Når så mye penger er i omløp er det en nødvendighet at man har tillit til sikkerheten i nettbutikkene.

Sikkerhet i nettbutikker

Sikkerheten som man må ha tillit til består av flere deler, hovedsaklig:

• Hvor sikker oppleves selve handelen?
• Hvor sikkert håndteres dine personlige data?
• Hvor sikkert håndteres betalingen?

Disse delene avhenger delvis av hva kunden selv gjør, for eksempel ved valg av passord, deretter av hvordan nettbutikkens funksjonalitet mot kunden er lagt opp, for eksempel bruk av kryptering, og til sist av hvordan de interne systemene er sikret.

Kundens lokale sikring av egen informasjon er kundens eget ansvar. Selv om tekniske hjelpemidler som sikkerhetsprogramvare og passordkalkulator kan hjelpe, er det i hovedsak bare opplæring og brukerens generelle årvåkenhet som nytter på dette området.

Tilsvarende, nettbutikken er ansvarlig for sikring av interne systemer og den lagrede informasjonen. For utenforstående er det vanskelig, om ikke umulig, å vite om nettbutikken faktisk har sikret systemene sine skikkelig, og man må som kunde ta det for gitt at de er sikret godt nok. Dersom nettbutikken mot formodning ikke har sikret systemene skikkelig er vanligvis den første indikasjonen man som kunde får om at det har vært noe galt at det publiseres store artikler i avisene om datainnbrudd hos nettbutikken. Man kan imidlertid få hjelp til å vurdere hvor gode systemer nettbutikken har dersom nettbutikken har blitt sertifisert av en uavhengig tredjepart, f.eks. organisasjonen Trygg E-handel.

Det eneste området av sikkerheten hvor man som kunde rimelig enkelt kan avgjøre om sikkerheten i nettbutikken er god nok gjelder hvordan nettbutikken er bygget opp og fungerer når du handler der.

Bruk av kryptering i nettbutikker

Når man handler i en nettbutikk går man gjennom flere steg:

1. Undersøke vareutvalget
2. Velge varene man vil kjøpe
3. Sjekke hva som er i handlevognen
4. Registrere seg som kunde, eller
5. Logge inn dersom man allerede er kunde
6. Gå til kassen med handlevognen
7. Oppgi hvordan varene skal leveres
8. Betale for varene

Min personlige oppfatning er at alle disse aktivitetene bør gjøres over en kryptert (sikker HTTPS) forbindelse, men det er nesten ingen nettbutikker som har implementert dette. Derimot er det ganske viktig at aktivitet nummer 4 til og med nummer 8 alltid gjøres over en kryptert forbindelse for å hindre at sensitiv informasjon kommer på avveie.

Etter at jeg i desember 2011 kom over en nettbutikk som brøt flere fundamentale regler for god sikkerhet i krypterte nettsider har jeg sett nærmere på hvor sikre flere grupper av nettbutikker er når det gjelder de første 6 aktivitetene nevnt ovenfor, og i løpet januar har jeg gjort en slik enkel undersøkelse av 34 norske, og 12 britiske nettbutikker. I denne undersøkelsen har jeg ikke sett på hva som skjer når man oppgir hvordan varen skal leveres og hvordan man skal betale (aktivitet 7 og 8), siden dette krever at man er registrert som kunde, og at man gjennomfører hele kjøpsprosessen, noe jeg ikke var interessert i å gjøre som del av denne undersøkelsen.

Utvalget av nettbutikker var stort sett kjente merkenavn i flere forskjellige markeder, og de fleste har også vanlige utsalgssteder.

Hver butikk ble sjekket for hvert aktivitetspunkt, og hvorvidt den nettsiden man kom til, og alle ressurser lastet i denne siden var kryptert. Hvis enkelte ressurser, selv bilder, ble lastet uten kryptering ble hele siden kategorisert som "ukryptert", siden det kreves omstendelige undersøkelser fra brukerens side for å finne ut hvorfor siden er markert som usikker. Dette gjaldt også sider hvor den krypterte siden var "gjemt" inne i en ramme på en ukryptert side.

Resultatet av denne undersøkelsen er mildt sagt skuffende:

• Bare to norske butikker, Boots og Kitchn, krypterte alle aktiviteter, mens ingen av de britiske gjorde dette.
• Over halvparten (52%) av de norske nettbutikkene benyttet *ikke* kryptering i det hele tatt (eller ikke godt nok) for de aktivitetene som ble testet, tilsvarende for de britiske butikkene var 16%.
• 26% av de norske butikkene krypterte aktiviteten for registrering, innlogging, og gå til kassen, men 67% av britiske butikkene gjorde dette. Inkluderer man også sikker visning av handlevognen ble tallene henholdsvis 12% og 8%.
• 35% hadde sikker registrering som kunde, sammenlignet med 75% blant britiske butikker
• 26% hadde sikker innlogging, sammenlignet med 75% blant britiske butikker
• 35% hadde sikker start på å gå til kassen, sammenlignet med 75% blant britiske butikker. Gå til kassen innebærer som oftest at man må logge inn.
• I en av de norske, og en av de britiske butikkene var disse tre aktivitetene riktignok kryptert, men inkluderte ukrypterte ressurser som åpnet for at en ondsinnet person kan ta full kontroll av den krypterte siden. Ytterligere to norske butikker blandet inn mindre farlig ukryptert innhold.
• I flere av de nettbutikkene som ikke benyttet kryptering for en aktivitet, men hvor det var mulig å aktivisere kryptering, viste det seg at disse variantene lastet ukryptert innhold, og i noen tilfeller åpnet
  dette sårbarheter i den krypterte siden.

Hvorfor bruke kryptering?

Hvorfor skal aktiviteter som registrering som kunde, innlogging, og gå til kasse alltid foregå over en kryptert forbindelse?

Svaret er at disse aktivitetene i det minste omfatter bruk av brukernavnet og passordet ditt, og kan også omfatte andre private detaljer som adresse og telefonnummer, eller adgang til disse, og noen ganger kan nok informasjon om personnummer være involvert. I mange tilfeller lagrer også nettbutikken informasjon om kredittkortet ditt i profilen din, slik at du slipper å taste det inn hver gang du handler, og i så fall kan en ondsinnet person som får tak i passordet være i stand til å endre profilen din, og gjennomføre handler med ditt kredittkort.

Når noe sendes ukryptert vil hvem som helst som er i kontroll av en ruter mellom deg og nettstedet, for eksempel i et trådløst nettverk, være i stand til å avlytte det som sendes, men kan også enkelt endre innholdet i det som sendes, og for eksempel legge inn kode som sender kopi av det som tastes inn til angriperen.

En mulig måte et slikt angrep kan gjennomføres på, er at noen plasserer et "gratis WiFi" nettverk ved et trafikk-knutepunkt hvor mange setter seg ned med mobilen eller PCen sin. Med den rette programvaren installert i nettverket kan man enkelt avlytte eller modifisere all ukryptert trafikk gjennom nettet.

I tre av de norske butikkene og to av de britiske ble brukernavn og passord som ble oppgitt på ukrypterte innloggings-sider riktignok sendt kryptert, men dette gir bare et bedragersk skinn av "sikkerhet", siden en ondsinnet person bare trenger å endre innholdet i den ukrypterte siden slik at den sender en kopi av brukernavn og passord til ham selv, i tillegg til den faktiske innloggingen til butikken. Det er egentlig ganske utrolig at man i 2012 fremdeles kan se slike innloggingssider i bruk.

I en av de undersøkte butikkene ble riktignok kryptering benyttet for flere aktiviteter, men dette var gjemt inne i en ramme (frame) som var laget av en ukryptert side, og den såkalt sikre siden inne rammen, hvor man kan bli bedt om personnummeret når man har valgt enkelte betalingsalternativ, brøt også de fleste reglene for hvordan sikre sider skal lages og åpnet for enda flere sikkerhetsproblemer. Effektivt vil det si at aktiviteten foregikk over en ukryptert forbindelse siden det ikke er enkelt å finne ut at rammen bruker kryptering (eller har flere andre sårbarheter), og en ondsinnet person kan veldig enkelt endre hva som skal vises i rammen, siden informasjonen om det blir sendt ukryptert og kan endres uten at det kan oppdages på noen enkel måte. Dette er også et annet eksempel på noe som ikke burde bli brukt av en seriøs nettbutikk i 2012.

Det er imidlertid ikke bare bruken av kryptering som avgjør om forbindelsen til en nettbutikk er sikker. Som en del av undersøkelsen sjekket jeg også status for en velkjent, men mindre synlig sårbarhet i de sikre tjenerne for de nettbutikkene som benyttet slike. Jeg fant da ut at bare 29% av nettstedene deres har oppgradert slik at de er beskyttet mot det såkalte "Renego" angrepet , som ble oppdaget, og fikset for 2 år siden, til sammenligning har 67% av de britiske nettbutikkene fikset problemet; og generelt har ca. 65% av alle sikre nettsteder fikset dette problemet. 53% av de norske butikkene som ikke er oppgradert er dessverre også slik konfigurert at de er sårbare mot det fulle "Renego" angrepet, hvor angriperen kan lure nettstedet til å utføre oppgaver med kundens ID. Forøvrig, norske nettbanker har det samme problemet, kun en av de 6 jeg har sjekket, Skandiabanken, har fikset problemet, og de fleste andre er i tillegg sårbare for angrepet (En stor bank har delvis fikset problemet i løpet av de siste ukene, men ikke fullført dette ennå).

Hva kan gjøres for å forbedre situasjonen? Først og fremst må nettbutikkene fikse nettstedene sine, men for å få god sikkerhet i det lange løp må man få på plass gode kontrollrutiner, for eksempel i form av sertifiseringsordninger, og ved at kundene holder et øye med sin egen sikkerhet.

Sertifiseringsordninger

Som nevnt ovenfor er det normalt vanskelig for utenforstående å kontrollere hvor godt en nettbutikk ivaretar sikkerheten. Dette skyldes at man må ha adgang til informasjon som de færreste bedrifter offentliggjør, av forretningshensyn. Det er imidlertid mulig at en uavhengig tredjepart undersøker bedriften og dens oppfyllelse av nødvendige krav, og dersom disse er oppfylt utsteder et sertifikat om dette.

Etter min oppfatning må disse kravene inkludere et krav om at kryptering brukes for all funksjonalitet som håndterer sensitiv informasjon må være kryptert.

Organisasjonen Trygg E-handel, som er en norsk sertifiseringsordning, har blant sine krav til nettbutikker at "Personopplysningene skal beskyttes mot ekstern inntrenging", noe som etter min oppfatning betinger at all håndtering av slik informasjon må foregå kryptert, siden man ikke kan beskytte et system mot "ekstern inntrengning" dersom passordet er enkelt tilgjengelig i ukryptert form på nettet. Likevel, to av de fire nettbutikkene i min test som var sertifisert av Trygg E-handel benyttet ikke kryptering for innlogging og registrering.

Hva kan kundene gjøre for å sikre seg at nettbutikken bruker god kryptering?

Først og fremst må kundene gjøre seg kjent med hvordan nettleseren deres indikerer at en side er kryptert. Denne indikasjonen har varierende utseende og plassering i de forskjellige nettleserne, og utseendet kan også variere med hvilken type sertifikat (identifikasjonskort) nettstedet presenterer til nettleseren, men er vanligvis assosiert med en "hengelås", slik som i Opera og Internet Explorer, men ikke alltid, siden Firefox benytter et litt annet utseende. I tillegg vises en spesiell, grønn variant av "hengelåsen" når nettstedet bruker et såkalt EV (Extended Validation) sertifikat, hvor informasjonen om nettstedet har blitt kontrollert spesielt grundig; slike sertifikater brukes blant annet av nettbankene, og bør brukes av alle nettsteder som krever betaling for varer og tjenester.

Bildet under viser eksempler på hvordan et ukryptert nettsted, et kryptert, og et nettsted med et Extended Validation sertifikat blir vist i forskjellige nettlesere.



Når en kunden går til en nettbutikk må han eller hun sjekke "hengelåsen" før de starter inntasting av brukernavn og passord, eller annen personlig informasjon, for eksempel under registrering, og før man starter betalingsprosessen. Dersom "hengelåsen" ikke vises skal man avbryte det man holder på med siden informasjonen ikke blir håndtert sikkert nok. Man bør også informere nettbutikken om hva man har observert.

Oppsummering

Basert på det som er vist ovenfor, vil jeg påstå at både den manglende bruken av kryptering, og den manglede oppgraderingen av nettstedene for å fikse kjente sikkerhetsproblemer, gir en klar indikasjon på at norske nettbutikker dessverre ikke er sikre nok.

Det kan også stilles spørsmåltegn ved om sertifiseringsordningene passer godt nok på dette området.

Manglende bruk av kryptering for sensitiv informasjon sender et signal til kundene om at man ikke har tenkt godt nok igjennom sikkerheten for nettstedet. Dette signalet er forhåpentligvis feil, men etter min mening kan det skape berettiget tvil om hvor godt sikkerheten er ivaretatt internt i butikken. Eller for å si det på en annen måte: Det er bra å låse bakdøren, men det nytter lite dersom hovedinngangen er vidåpen.

Jeg vil på det sterkeste oppfordre norske nettbutikker om å ta sikkerhet og bruk av kryptering på alvor. Dersom nettstedet ikke bruker kryptering for sensitiv informasjon bør det fikses raskest mulig, og dersom det ikke kan gjøres umiddelbart bør strengt tatt nettstedet tas av luften inntil problemet er fikset.

Det er synd å si det, men dessverre tror jeg at det ikke blir noen stor bedring før noen gjennomfører et angrep, eller kundene blir mer observante, og stemmer ved å flytte sine museklikk til nettbutikker som passer bedre på kundenes sikkerhet.

Over the past few years browser vendors have been steadily raising the bar for what can be called secure connections and documents. SSL v2 has been phased out, as has 40- and 56-bit encryption. Extended Validation (EV) has been introduced to provide better identity assurance, and the W3C is about to release the Web Security Context UI specification to make the security indicators more consistent.

There is, however, (at least) one area where this development has not come as far as I think it should have: Unsecured content is still allowed in secure documents. Some clients do give the user a warning (MSIE for example, Opera and FF do not), but as far as I know none show a padlock for such pages.

Some may wonder why such mixing is a problem, so here is a short description of some issues:

• Unsecured content can be read by anyone listening in the connection (Not very polite of them)
• Even worse, somebody listening in is almost always in a position to change the content (But, that's ... criminal, right?)
• Some content, like images, can tell the eavesdropper what you are doing.
• Other content, like JavaScript and CSS, can directly change the content or appearance of the webpage. If modified by an attacker, the page could be made do things you neither you nor the designer would like, like send your password and credit card details off to the attacker.

Therefore, using unsecured content in an otherwise secure document can, in some cases, leak information, while in others it can compromise the security of the *entire* site.

A very "popular" excuse for using mixed security in a site is that it reduces load on the server, because of the cost of SSL connections. This excuse was debunked by Bob Lord (formerly of Mozilla) a few years ago. The most costly operation for a secure secure server is the private key decryption step of the initial SSL handshake, and on a well-configured server that is an operation done no more than once a day per client. The remainder of the extra work is the encryption, and modern encryption methods like AES have been designed to be as efficient as possible. Both of these operations can be performed using hardware accelerators, which should reduce your total hardware cost if you do have heavy traffic to your site.

By ensuring that your server is serving HTTP 1.1 content, that it properly support and specify cache directives, persistent connections and pipelining, that you can maximize your server's efficiency. If you still think your site is under too heavy a load, perhaps you can reduce the complexity of the documents, simplify images and scripting, and rely on CSS to place the content correctly?

In most cases where we see mixed-security content used these days, the reason is not cost reductions, it is due to copying code, for example an analytics JavaScript tag, without examination of the code, forgetting to change the URL to https, and during testing not noticing the security warnings some browsers do show (unless the testing is not done on a secure site, but an unsecure one, which might explain some of the curious aspects of this).

In my opinion such mixing is long past its use-by date. It may have been (or seemed) necessary in 1998, but not in 2010, especially with the much more hostile environment that now exists, such as phishing, malware, and the possibility of compromised WiFi networks.

During beta testing of IE7 Microsoft tried to block mixed-security content by default, but apparently found that "too many" sites broke, and backed down.

I wish Microsoft had not backed down. The "problem" with secure sites not working "properly" when blocking unsecured content will not disappear, and will have to be handled if/when blocking is reactivated. In my opinion, any such problems with broken sites will be short-lived, and the sites will probably be fixed within weeks of a policy shift.

One might hope that fewer sites are doing using mixed-security content when browsers start to block that type of problem, but I would not hold my breath.

However, I continue to see hotel booking sites, bank sites, and other important sites loading unsecured content as part of their secure pages, and even new sites do it.

In recent weeks I have noticed two high profile sites with such mixing of secure and unsecured content: Twitter and Citibank. In both cases the pages in question included external JavaScripts, which would allow an attacker to completely replace the content of the site, and, for example, to use it to steal passwords.

Twitter (contacted June 3rd) have recently been updating their site, including a secure site interface, but have not yet removed all the references to unsecured content on its main page. According to my information, they are working on it.

In <http://www.citi.com/> Citibank's case (contacted June 17th) there are two problems: Their main landing page is not encrypted, and the "Unknown page" (404) error page (e.g. the page for https://www.citibank.com/foo ) on one of their secure severs includes unsecured scripts, meaning that a MITM attacker can replace their main page (by editing the network traffic, for example in a WiFi-router) and is able to redirect the user to a server where he is (by replacing the unsecured script) in complete control over the content. The only way for a user to discover that he is under attack is to notice that there is no padlock and/or that the URL is not the one Citibank actually use for the service they are supposedly using, even though the URL belongs to Citibank.

I think that this is a big chink in the bank's security armor, but apparently Citibank does not think so, referring to the fact that the vulnerable server is not their main site any more (which does not matter as long as the server is online), that their services are secured with encryption (and that does not matter if the attacker can trick the user into believing they are on the right site) and that they have other security policies in place to help users in case their account is compromised. My impression is that they are not planning to fix the problem.

The problem with mixed-security sites will not disappear while they are allowed to work, so we do not gain anything by waiting, rather the opposite.

While I think blocking unsecured content in secure pages is the best solution, there are others who think that one should warn the user with a dialog, or display the page without any indication that it is partly loaded from a secure server, for example by removing the "https" in the URL displayed in the addressbar, or showing it as crossed out, because we "should allow sites to shoot themselves in the foot if they absolutely want to".

The problem with the warning dialog is that most users will usually just click through it to continue their business. Crossing out https is not much different from what clients do today, by not showing a padlock, and the problem with allowing sites to "shoot themselves in the foot" is that the foot actually belongs to the user.

In my opinion, blocking the mixing of secure and unsecured content is the best option, perhaps with an option for the user to manually trigger loading of the unsecured elements. It may break sites during a transition period, but such sites will be quickly fixed if the issue is critical for the site. The end result will be a more secure web.

In standards work, there is a suggestion being circulated which might help in this area: HTTP Strict Transport Security(a video of a presentation by the author is available here). HSTS is designed to let sites specify HTTPS as the only allowed connection method for their site or domain, amd it contains a suggestion to browser implementations that they block mixed-security content. However. it would only work for sites that ask for such a policy.

This is an area where few browser vendors, if any, can make a move on their own, but by joining forces we might be able to do something about the problem.

I therefore urge Adobe, Google, kHTML, Microsoft, Mozilla, Opera, and Safari, as well as other browser and framework vendors, to discuss a common solution to this issue, and agree on a time-line for when we will ship browsers and frameworks that implement that solution.



Previous articles on this topic:

• Secure sites that aren't
• Low security sites, what to do about them?

As discussed in this Security Group article, a serious vulnerability in the SSL and TLS protocols renegotiation was discovered last year.

The update of the SSL and TLS protocol to fix the "Renego" vulnerability was published earlier today.

The RFC can be downloaded from http://www.rfc-editor.org/rfc/rfc5746.txt

As mentioned in the article, Opera 10.50 Beta 1 includes support for the updated protocol, although it is not fully activated yet due to usability reasons. In related news, Mozilla included support in their nightlies earlier this week.

The Opera Security group just got its own home page.

"Security @ Opera" is where we will post information about security advisories, as well as occasional articles about security related topics.

The first article is about the recent developments concerning MD5 in SSL/TLS certificates.

There's been a number of criticisms directed at the padlock over the years, some of which may be correct, to some extent, at least.

One objection has been that users misunderstand the padlock's meaning, thinking it is an indicator of trustworthiness, rather than a protection rating for the connection.

Another objection (which flies in the face of the first), is that "nobody checks the padlock".

Well, I can't say much about the correctness of the first objection, but the past couple of weeks a growing number of Opera users have been working hard at debunking the second one.

In Opera 9.50 we added some new security features, and changed a some others. Two of these are the following:

• We now use HTTP GET requests to retrieve OCSP revocation information
• Additionally we download further revocation information, the CRLs (Certificate Revocation Lists), from the issuer and check those.

Both of these turned out to encounter unexpected problems, not due to bugs in our implemenation, but at the CA side. In all cases the problem cause full validation of the certificates to fail, and as a result Opera reduces the security level of the connection so that a padlock will not be displayed. Quite a lot of people noticed.

For OCSP we encountered problems with at least three different brands of OCSP responders. These responders did not respond correctly when we sent a request for infromation about a certificate. It wasn't until a couple of weeks ago that the vendor for one of them discovered the reason for the problem, their expectation of input format was wrong. According to my information they have developed a patch, and I assume they are doing QA on it now, before sending it to the two (or more) CAs that are affected by this. The others have shown up recently and I do not have good information about the causes.

With CRLs we encountered two problems. Just before 9.50 was released we got the first reports about the first case, but it was not until a few days after the release that we got an overview of the situation.

It turns out that one specific CA created an intermediate certificate a few years ago for one of their certificate hierarchies. This certificate included an incorrect URL for where we should go to fetch the CRL, so when Opera fetches the CRL it gets a CRL created for a different hierarchy than the one being verified. As a result Opera's ceritificate validation code can't find the right CRL, and this step fails. This certificate became installed on thousands of servers before the mistake was discovered, and despite a campaign to replace the certificates, several hundred sites (many of them banks) still use the old certificate.

In another case, which came to light last week, another CA have issued an intermediate certificate directly below their root that does not contain a URL for a CRL, but the sub-ordinate certificate issued from that intermediate does specify a CRL. As Opera's certificate validation code expects that if one certificate have a CRL they all use CRLs, validation of the topmost intermediate certificate fails because it can't find the CRL for that certificate.

What can be done about this?

• About the OCSP issue, we wait for the vendor patch, but in Opera 9.51 we have added an override that lets us use the certificate update system to specify which OCSP URLs that must use the old POST method. In addition one CA also deployed a workaround.
• About the first CRL issue, the websites need to update their installed certificates, in the second case the CA must also issue a new updated certificate. While waiting for that, in 9.51 we are adding a similar override mechanism as for OCSP, by specifying extra CRL download locations for specific CAs. In the second case we might also be able to fix the issue if the CA has a root for that particular CA name by distributing it to all installations that access the affected sites (that is not a realistic option for the first case).

These changes will be active in the upcoming Opera 9.51 RC2 (Update: Now available), and is already active in the online certificate repository. You will get the updates the next time Opera checks for updates, or if you use Help->Check for updates.

Update July 9: There are some sites with certificates that does not provide any CRL or OCSP information in the site certificate, while the rest of the certificate in the chain have CRLs. Due to a minor bug, and restrictions in the override functionality, the override for that will not become active before 9.52 has been released. At present we are only aware of 10-20 sites affected by this.