Implementer's notes

Since my last update about the OCSP Multi-stapling draft, a number of things have happened: the document have been approved by the IETF's steering committee (IESG) for publication as an RFC, and the IANA have now assigned the code-point (#17) to identify the new "status_request_v2" TLS Extension. The RFC Editor is currently processing the document.

In related news, the Certificate Authority Security Council have today posted my article "An Introduction to OCSP Multi-Stapling".

[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]

In the past half year, there have been a number of developments regarding the standards drafts I have been working on.

TLS Multi Stapling draft has become a TLS Working Group item

At the March IETF meeting in Paris, the TLS Working Group decided, and confirmed by the mailing list in late April, to accept my draft for fixing and expanding OCSP Stapling into "Multi Stapling" as a Working Group item.

Since then, the draft have been updated twice. The update released this summer included, as a trial, support for the Server-Based Certificate Validation Protocol (SCVP) mechanism. The text for that was mostly contributed by Sean Turner, one of the IETF Security Area Directors.

Unfortunately, there was not much interest expressed from the Working Group for or against this expansion of the draft. I therefore decided to remove the SCVP text from the draft when I updated it a few weeks ago.

How to prevent version rollback attacks against TLS clients and servers?

The SSL and TLS protocol has a mechanism that is intended to allow clients and servers that support different versions to negotiate the highest mutually supported version (the client sends its highest supported version, the server picks the lowest of its highest version and the client version) and to prevent an attacker from forcing the parties to negotiate an older version of the protocol (a version rollback attack) that might be easier to break.

This is done in two different ways:

• First, the integrity of the entire handshake is checked when the client and server exchange the first encrypted packets. As long as the method used to check the integrity (a digest method or hash function, e.g., SHA-1 and SHA-256) is secure, this will prevent a successful version rollback attack.
• Second, the RSA-based method for agreeing on the TLS encryption key is defined in such a way that the client also sends a copy of the version number it sent to the server and against which the server is then to check against the version number it received. This would protect the protocol version selection, even if the hash function security for a version is broken. Unfortunately, a number of clients and servers have implemented this incorrectly, meaning that this method is not effective. Additionally, this method is only possible to use for methods like RSA and not others like those based on Diffie-Hellman (DH) or Elliptic Curve Cryptography (ECC).

However, ever since TLS 1.0 was introduced by TLS clients, they have had to deal with legacy servers that did not respond well to being presented with a TLS 1.0 (or higher) version number from the client. The servers would just shut down connections, return error codes, or respond in other bad fashions. Once clients started supporting TLS Extensions, the situation got even more complex, since a large number of older servers would not accept connection attempts from clients sending TLS Extensions, despite all versions of TLS requiring it.

In order to let users actually access such sites, if the connection initially failed, the browser clients offered an older protocol version (down to SSL v2 while that was offered, then SSLv3) until one of them worked.

The result: All clients voluntarily subject themselves to a version rollback attack, and none of the built-in protection mechanisms work.

This has been an issue for at least 13 years, and it has never been fixed, since doing so would break "too many sites" (at present, 1.36% of all servers). Another factor is that the issue is still considered hypothetical, since there are no known attack able to break any version of SSL 3 or TLS 1.x.

In December 2009, during the work with the TLS Renego patch specification, I suggested to the TLS WG that clients could use the Renego Indication extension (the Renego patch) being used by servers as an indication that the server is TLS Version and Extension tolerant, and that they should not perform version rollback when connecting to such servers. While the outcome of that discussion was a reminder in RFC 5746 (the Renego patch specification) that servers MUST accept TLS Extensions and higher version numbers than they support, unfortunately the Working Group did not decide to add a requirement that clients must not permit version rollback recovery against Renego patched servers. I did, however, implement such a policy in our implementation of the patch in Opera 10.50.

Recently (in the past year, or so), there have been more discussion of this topic, starting with a suggestion by Eric Rescorla (aka EKR), one of the TLS WG co-chairs, about using special Cipher Suite values in the TLS handshake to indicate the version, and Adam Langley from Google followed up with a slightly different version of the same concept.

I do not like the proposed solution, for several reasons:

• It would require updates of all clients and all servers. Considering that, 3 years after the Renego disclosure, a serious protocol vulnerability, we have still not passed 75% patch coverage in my TLS Prober sample (it is currently 73.7%), and that this is will likely be considered a less serious problem to patch, I believe we would be very lucky to see over 50% coverage after the same time period.
• The logic around such a system would be complex, and needing a value for each defined TLS version would make it even more complex. There are also issues with how the server and client should behave in the event a mismatch is noted between the two version indication systems. Should the server upgrade the connection? Should it return an error code, and, if so, what should the client do? Something else?
• Any server that would be updated with this system would, by definition, already be version and extension tolerant. It would also already be patched for the Renego problem, probably years earlier.
• This solution would do nothing to protect connections with servers that are version and extension tolerant, which is 98.3+% of servers in my sample.
• This suggestion reuses a concept, the Special Cipher Suite Value or SCSV, that was introduced by the Renego patch as a hack to allow clients to signal their Renego patch status to the server when they are not sending TLS Extensions, such as when connecting to extension-intolerant servers. That was done to fix a serious security vulnerability, for which there was no other channel to convey the necessary information. In this case, I believe there are other, better methods to convey or deduce the information.
• The SCSV concept should be only be used as a last resort, when nothing else will do the job. If its use is allowed too often, it becomes easier to select it, and it ends up becoming a substitute for the TLS Extension mechanism. In fact, there has been at least one other suggestion to use SCSVs as a signaling mechanism in the last year, which did not have a really good rationale for using the concept, in my opinion (and the Working Group did not think it would produce the desired security result, either).

In my opinion, it is better to discover and use a way to reliably discover that the server is version and extension tolerant, and use that as a proxy indication, and I think the TLS Renegotiation Indication Extension (the Renego patch) is as nearly a perfect proxy indicator as we are going to find.

• The Renego patch RFC contains, as mentioned above, a reminder to implementers that version and extension tolerance is expected, and this recommendation has (mostly) been followed.
• While this method would not protect all of the 98.3+% of tolerant servers, it would immediately protect connections with the 73.7% of all servers that already support the Renego patch (based on the 571000 servers sampled by the TLS Prober).
• Of the Renego patched servers, only 0.17% are version and/or extension-intolerant, compared to 4.7% of the unpatched servers.
• Of the patched, but intolerant, servers, 33% are in a special category: they do not tolerate a specific TLS extension, either the Server Name Indication extension or the Certificate Status extension. I have yet to discover the reason for this intolerance among a small group of servers, but there are indications that some kind of TLS front-end is involved, and the largest collection of servers we have found is a group small online banks hosted on a single 256 IP address subnet by the banking ISP Jack Henry & Associates.
• When clients stop supporting Renego unpatched servers, they can immediately remove the code supporting version rollbacks, too, since the Renego patched servers will not require that functionality.

This means that it would be possible for clients to use the Renego patch to protect connections with 73.7% of the servers on the web, immediately, by not allowing version rollback when connecting to a patched server.

While the small number of problematic servers could cause some to be concerned, I believe that this small number of servers (712 of 421,000 servers) can be quickly fixed by their owners once they learn of the need to do so. I think it is much more of a problem what most users will be connecting to these sites using the obsolete, 17-year-old, SSL v3 protocol.

As there were other proposals on the table, I decided to write up my proposal as an Internet Draft and submit it to the IETF TLS Working Group for consideration. So far the topic has been discussed at one meeting, in Vancouver, but no decision about which approach to use has been made yet.

In my opinion, my proposal is the quickest and best way to remove the current system of automatic version rollback from use, while still maintaining compatibility with Renego unpatched servers that are version and/or extension-intolerant.

As mentioned, Opera has already implemented the proposed method, and thus has already protected its users against a version rollback attack when connecting to Renego patched servers. Unfortunately, this does create a couple of problems, since sites such as www.glacierbank.com, www.banksafe.com, and www.bigskybank.com do not follow the TLS specification, and require the client to perform a version rollback, even if they are Renego patched, because they do not tolerate the Certificate Status extension; therefore Opera is not able to connect to them.


Public Suffix information moving into the DNS?

Over the past several years, I, among others, have been working to convince the IETF to look at the problems around domain limitations around cookies and other cross-site information sharing, as demonstrated by the difficulty of preventing cookies being sent to all web servers in domains like co.uk, most commonly called Public Suffixes. This has been difficult, since many in the DNS community are very opposed the concepts that Public Suffixes involve.

In the meantime, the world has moved on, Mozilla completed its work on creating the Public Suffix List, and, in other areas of internet technology, concepts that required information provided by the Public Suffix List kept showing up.

One of the main issues with a system like the Public Suffix List is the problem of maintaining the list as an up-to-date resource. Currently, the information in the list has to be manually collected from many diverse sources, checked, and included in the list. As the number of Top Level Domains increase, not just with new internationalized country code TLDs (such as for many non-western countries), but ICANN is currently working to introduce hundreds of new generic TLDs every year, the amount of work needed to maintain the list will increase rapidly, and the list would in any case never be really up to date.

At the March IETF meeting in Paris, in a small meeting with several interested parties Andrew Sullivan, Co-chair of the IETF DNS Extensions Working Group, volunteered to investigate how to better implement the public suffix system in DNS. His suggestions are available in his document "Asserting DNS Administrative Boundaries Within DNS Zones".

As we now have started on a route to system that I hope will be better than the one I have been proposing, I am now suspending work on the SubTLD Structure draft. Opera will still generate the XML files we use to distribute Public Suffix information, but the work of developing the XML format into a suggested standard for distribution and aggregation of Public Suffix information will end.

Work on other drafts suspended

At present, the IETF HTTP Working Group is busy defining a new HTTP 2.0 specification, based on SPDY. Therefore, it is unlikely that my drafts for Cache Context and Cookie Origin will be taken up by the HTTP Working Group. It may be that this group, and the planned HTTP Authentication Working Group, will take a look at these areas and try to solve the issues those two drafts seek to address.

Given the low probability of an IETF Working Group taking up the drafts as Working Group items, and the general lack of interest expressed from other parties, I am suspending work on these drafts, as well. However, I may resume work on them if enough interest is expressed from relevant parties, particularly web developers and relevant websites. With enough interest and participation, it might be possible to refine either, or both, of these drafts and submit them for consideration as Individual Submission RFCs.


Archive:

draft-ietf-tls-multiple-cert-status-extension-00 (archive)

draft-ietf-tls-multiple-cert-status-extension-01 (archive)

draft-ietf-tls-multiple-cert-status-extension-02 (archive)

draft-pettersen-tls-version-rollback-removal-00 (archive)

[This is the English version of a Norwegian article I posted February 14]

Online shopping is increasingly representing a large portion of the economy. In Norway, the size of this trade was estimated to be NOK 48 billion (USD 8.4 billion) in 2011 by DIBS (a Scandinavian payment processor) according to an article in Digi.no/NTB. That amount is, however, just under half of Amazon's USD 17 billion sales revenue in the 4th quarter of 2011.

When so much money is changing hands, it is important for consumers to have confidence in the security of online shopping sites.

Security in online shopping sites

The security we need to be confident about consists of several components, primarily:

• How secure is the shopping experience itself?
• How securely is the personal data handled?
• How securely is the payment handled?

These components depend in part on what customers do, such as how they select passwords, then by how the shopping site is organized, e.g., its use of encryption, and, finally how the internal systems are secured.

Securing the customer's local information is the customer's own responsibility. Even though technical aids like security software and pin-code calculators can help, it is mainly education and the user's own vigilance that really help in this area.

Similarly, the shopping site is responsible for securing internal systems and the storage of private information. For an outsider, it is difficult, if not impossible, to know if the shopping site has properly secured its systems, and as a customer you have to assume they have done so. If, contrary to expectations, the shopping site has not secured their systems properly, the first indication of a problem will usually be large articles in the news about a break-in at the site. It may, however, be possible to get assistance in evaluating the security at a shopping site, if the site has been audited by an independent third party, such as the Norwegian organization Trygg E-handel ("Safe e-shopping").

There is only one security area where a customer can determine, with relative ease, how good the shopping site's security is: how the shopping site is designed and how it works while you are shopping.

Use of encryption

When you are shopping in an online store you go through several activities:

1. Explore the shop and its selection of goods.
2. Select the goods you want to buy.
3. Check what is in your shopping cart.
4. Register if you are a new customer. (Or, if you are already a customer, proceed to activity #5)
5. Log in if you are already a customer.
6. Go to the checkout area with your shopping cart.
7. Enter shipping details.
8. Pay for the goods.

My personal opinion is that all of these activities should be done over an encrypted (secure HTTPS) connection, but almost no online shopping sites have implemented this. However, it is very important that activities number 4 through 8 are always performed over an encrypted connection to prevent leaks of sensitive information.

After my December 2011 discovery of an online shop that broke several fundamental rules for good security in encrypted webpages, I have looked more closely at several groups of online shopping sites with respect to the first 6 activities above, and, in January I performed a simple survey of 34 Norwegian and 12 British online shopping sites. During this survey, I did not look into what happened when shipping and payment details are entered (activities 7 and 8), as these activities require that you are registered as a customer and complete the entire shopping process, which I was not
interested in doing as part of this survey.

The selection of shopping sites mostly included big brands in various Norwegian or British markets, most of which have brick-and-mortar stores, as well.

Each shopping site was checked for each activity point and evaluated based on whether the page a customer landed on, and all other resources (images, scripts, etc.) that were loaded as part of the page, were encrypted. If any resource, even an image, was loaded without encryption, the entire page was deemed "unencrypted". The reason for this requirement is that it requires a non-trivial effort by a user to determine why a page is marked as unencrypted by the browser. This was also done for pages where the encrypted page was "hidden" inside a frame in an unencrypted page.

The results of this survey are, to put it mildly, disappointing:

• Just two of the Norwegian shops, Boots (which might be considered international) and Kitch'n, encrypted all activities, while none of the British shops did.
• More than half (52%) of the Norwegian shopping sites did not use encryption at all (or not well enough) for the activities that were tested. The corresponding number for the British sites was 16%.
• 26% of the Norwegian sites encrypted the activity for registration, login, and "go to checkout", while 67% of the British sites did the same. If we include secure display of the shopping cart, the numbers became 12% and 8%, respectively.
• 35% had secure customer registration, compared to 75% of the British sites.
• 26% had secure login, compared to 75% of the British sites.
• 46% had secure start on "go to checkout", compared to 75% of the British sites. For "go to checkout", this usually means that you have to log in.
• At one of the Norwegian and one of the British sites, these three main activities were admittedly encrypted, but they included unencrypted resources that would enable a malicious person to gain complete control of the encrypted site. Another two Norwegian sites included less dangerous unencrypted content.
• At several of the shopping sites where encryption was not used for an activity, it was sometimes possible to activate encryption by changing the URL, but, in many of these cases, the resulting pages included unencrypted content, and, in several cases, this created vulnerabilities in the encrypted document.

Why should encryption be used?

Why should activities like customer registration, login, and "go to checkout" always be encrypted?

The answer is that these activities, at the very least, require use of your username and password, and may also ask for other private details such as address and phone number, or provide access to them, and sometimes information about your social security number may be involved, too. In many cases, the shopping site will also store information about your credit card in your profile, meaning that you don't have to type it every time you're shopping. In such cases, should malicious persons get hold of your password, they can go shopping with your credit card.

When something is sent unencrypted, anyone who is in control of a network router between you and the shopping site, such as in a wireless network, would not only be able to listen in on what is being transmitted, but would also be able to easily change the content being transmitted, which could include adding code that sends a copy of whatever is entered on the page to the attacker.

One possible way such an attack can be carried out is that somebody places a "Free Wi-Fi" network in travel hub (e.g., a railway station, bus station, or airport) where many people will sit down to use their mobile phones or PCs. With the right software installed in the network, it is very easy to listen in, or even modify, the unencrypted traffic crossing the network.

On three of the Norwegian sites, and two of the British ones, the usernames and passwords that were entered on unencrypted login-pages were admittedly sent encrypted, but this only provides an illusion of security, since an attacker can easily change the content of the unencrypted page so that a copy of the information is sent to a different destination in addition to the real login to the shopping site. It is worth noting that Eric Lawrence of Microsoft called this "Critical Mistake #1" in an IEBlog article back in 2005. It is rather incredible that we are still, in 2012, seeing this kind of login page being used.

For another of the shopping sites, several activities were encrypted, but this was hidden away inside a frame that was hosted on an unencrypted site. Also, the allegedly-secure page inside the frame, where you might be asked for your social security number, turned out to be violating most rules about how secure pages should be constructed and opened multiple security vulnerabilities. Effectively, the activity was done over an unencrypted connection, as it is not trivial to discover that encryption was used in the frame or that it suffered from several vulnerabilities, and an attacker can easily change what is actually loaded in the frame, since the instructions are sent unencrypted. Such replacements cannot be discovered easily. This is another example of web design that should simply not be used by a serious shopping site in 2012.

It is, however, not just use of encryption that determines if the connection to the shopping site is secure. As part of this survey, I also checked the patch status for a less visible vulnerability that I have discussed many times before, mostly on the Security Group home page: the "Renego" issue, which was discovered and patched over two years ago. I discovered that only 29% of the Norwegian shopping sites had upgraded their servers to patch this problem, while 67% of the British sites had done so (the general patch rate is now 65%). In all, 53% of the unpatched Norwegian sites were also configured in such a fashion so that they were vulnerable to a full "Renego" attack, allowing an attacker to inject commands to the website and have them executed with the user's credentials.

What can be done to improve the situation? First, the shopping sites must fix their sites, but, in the long run, we need good control routines, such as by certification services, as well as customers learning to keep an eye on their own security.

Certification services

As mentioned above, it is usually difficult for outsiders to determine how good the security of a shopping site really is. This is due to the fact that, to be able to do that, we need access to information that companies for business reasons seldom make available. It is, however, possible that an independent and trusted third party might be allowed to audit the company and its compliance with specific requirements, issuing a certificate or seal if the requirements are met.

In my opinion, such requirements should include a requirement about using encryption for all functionality that handles sensitive information.

In Norway, the organization Trygg E-handel is such a certification service. Among its requirements for online shopping sites, it states that "Personal information must be protected against external access" (my translation), which, in my opinion, requires that all handling of such information must be encrypted, as you cannot protect a system against "external access" if the unencrypted password is easily available on the net. Still, two of the four shopping sites in my survey that were certified by Trygg E-handel did not use encryption for login and registration.

What can the customer do to ensure that a shopping site uses good encryption?

Primarily, customers must make themselves familiar with how their browsers indicate that a webpage is encrypted. This indication appears with slightly different designs and locations across the various browsers, and the indication can also change, depending on which kind of SSL certificate the server presents to the browser. It is, however, frequently associated with an image of a padlock, such as in Opera and Internet Explorer, but not always; Firefox is currently using a slightly different presentation. In addition, most browsers show a different, green variant of the padlock when the secure site is using an Extended Validation (EV) certificate for which the information has been extensively checked. Such certificates are frequently used by online banks and should be used by any site that charges payment for goods and services.

The following picture shows examples of how an unencrypted site, an encrypted site, and a site using an Extended Validation certificate are presented in various browsers:



When customers visit an online shopping site, they must check the padlock before starting to enter usernames, passwords, and other personal information, such as during registration or before starting the payment process. If the padlock (for either normal encryption or Extended Validation) is not displayed, you should not continue the transaction, but instead leave the site, as the information is not handled securely enough. You should also inform the shopping site about what you observed.

Summary

Based on the above, I would say that the lack of encryption, and lack of timely server upgrades to fix well known security problems, clearly indicate that Norwegian shopping sites are not secure enough.

The question is what these findings indicate about the security of shopping sites in other countries? Given the numbers for the British sites mentioned above, as well as the findings in my e-bookstore survey in December of about 50% of surveyed shops using good encryption, (which may be too few datapoints to be really significant), there is at least a good indication that there is still a lot of room for security improvements in the online shopping industry.

At the very least, based on the single certification service I reviewed, I would say that these services still have room for some improvement in the security area.

Not using encryption for sensitive information sends a signal to customers that a business has not given sufficient attention to the security of its shopping site. This signal is, I would hope, mistaken, but I am afraid that it can create a justified doubt about how well the shopping site's internal security is handled. Or, to put it another way: It is a very good practice to lock the back door to your house, but that won't help you if the front door is wide open.

I urge online shopping sites to take security and the use of encryption seriously. If a shopping site is not using encryption for sensitive information, this should be fixed as quickly as possible, and, if repairs cannot be completed within a short time, then the site should, strictly speaking, be taken offline until the problem has been fixed.

It is a sad thing to say, but, unfortunately, I doubt that there will be any significant improvement until somebody completes an attack (as happened to the social websites with the Firesheep utility), or until customers become more observant and vote by moving their mouse clicks to online shopping sites that guard their customers' security better.

E-books have not been something I have been reading too much of, since I am rather old-fashioned about books, preferring physical books (and I probably spend way too much time in front of computer monitors, anyway). Among other nice things about them is that you don't have to turn them off aboard a plane during take off and landing .

Despite this I actually do have a collection of e-books on my PCs, since Baen Publishing, a Science Fiction and Fantasy publisher, has been kind enough to include CDs with several of the hardcover books I've bought from them. The CDs contain the books in several formats, including HTML, all unencumbered by DRM, even with a permission for non-commercial sharing. Baen do this because they think they will sell more physical books, and as far as I can tell it works like a charm: I bought a bunch of paperbacks from the first CD, and I know one of the authors published by Baen, Eric Flint, did some research, finding that he sold more books than he normally would have, after he had made his available for free (see this article collection, search for "There Ain’t No Such Thing as a Free Lunch" and "I can demonstrate this concretely").

Until a month ago I had not been looking into Baen's WebScription service, their e-book store (they also have a free library), since, as I mentioned above, I prefer physical books. A month ago, however, I became aware that Baen had, as they frequently do, made an early version (an ARC, Advanced Reader Copy, before proofreading) of a book I was waiting for (it will be published in March, already pre-ordered), so I decided I did not want to wait that long , "walked" over to Webscription, registered and bought the early version (without encountering any problems with the security of the website).

Then, a couple of weeks ago, as I was winding up the backlog of books in a series (in case anyone is interested: the Lee&Miller Liaden Universe Saga - finally decided it was time to get started on that one, while flying across the Atlantic) that I've been reading the past few months, I found that there were a few collections of shorter stories available, particularly as HTML e-books (without DRM). Most of them were available via WebScription, but not all of them.

The remaining books were available through another e-book service, Smashwords, and that's when I hit the first security warning. I had followed links from Lee&Miller's home page to the Smashwords pages for the books, and clicked "Buy". Up came the the "You are about to submit an unsecure query from a secure page"-warning. What's going on? The link from Lee&Miller was (unusually enough) for a HTTPS page, most shopping sites use unencrypted pages for the presentation, so I had not noticed, and the "buy"-button was submitting a form to an unsecure server.

This, of course, triggered some more investigation, and I quickly discovered that the HTTPS page I was on was not just posting to an unsecure server, it also included an unsecure external JavaScript, in a page that also had a login form at the top (most pages had that login form, also the unencrypted ones). As I have mentioned before, this means that if anyone logs in through this page, an attacker could replace the original script, steal the account information, and assume control of the account (including the accounts of authors publishing at the site).

I also discovered that the "buy" action that submits to the unsecure server (which triggered the initial warning dialog), bounces back to a "secure" page that says you have to be logged in to see the shopping cart. This "secure" page includes both an unsecure CSS file, and an unsecure external JavaScript file, which again means that a attacker can take complete control of the user experience, and steal account data and, very likely, credit card information.

I informed Smashwords about the problems on or around December 2nd, and again December 15th after I had received no response from them, and the problems still remained. As of December 20, still nothing has happened.

After this I decided to check out a few more e-book shopping sites, and did a quick test of 14 more sites found via a wiki page, which along with Smashwords, totaled 15 sites. In this quick test I tested their support for secure presentation, sign up, log in, how securely the shopping cart was presented, and the checkout up to having to log in before being able to continue. In none of these cases did I create an account or attempt to log in, so the investigation did not test how secure the payment systems are.

• One (1) site did not seem to provide any encryption at all. This one seemed to mostly offer free content.

Front page:

• 5 sites provided a secure variant of their front page. All five of them had mixed secure and unsecure content, 4 of the 5 included unsecure JavaScript.

Presentation:

• 3 sites provided a secure variant of the book presentation. All three of them included unsecure JavaScripts.

Shopping cart:

• 6 of the sites provided a secure variant of the shopping cart, only one had that as the default, 3 others included unsecure JavaScript, another unsecure images.
• 3 more required log in on a secure page before displaying the shopping cart, one mixing unsecure images, one unsecure JavaScript.

Sign up/Log in:

• 14 of the sites provided default secure sign up and login pages, but 3 included unsecure external Javscript, another two used mixed security content.

Checkout:

• In two cases it was not possible to get to checkout, due to login requirements for even adding items to the cart.
• In another three the checkout was login protected.
• in the remaining 9 cases, 3 were including external JavaScript, and one mixed security content.

In total, ignoring the pre-checkout navigation, for the sign up, log in, and checkout parts of my test:

• 8 of the 15 used full encryption, without mixed security.
• 4 included unsecure JavaScript, with some also including unsecure CSS style sheets. Some of these scripts were these scripts were Facebook related or analytics-scripts. Three of these were informed yesterday, Smashwords was, as mentioned, informed a few weeks ago.
• 2 others included mixed security content.
• (and one did not provide any security, at all).

In other words, only half of the tested e-book sites followed the minimum best practices for e-commerce (secure sign up, sign in and checkout, no mixing of secure and unsecure content), and a full two thirds of the rest leave their sites wide open to a JavaScript-based Man in the Middle hijacking of accounts, and in at least some cases this appears to include the author's accounts too.

So, my advice is that you should be vigilant when you are online shopping for e-books, and probably in other online shops, as well. Frequently, when the "secure" indication for a "secure" page is gone, only a detailed investigation will indicate if the problem is a true security problem, so it is better to assume that it indicates that there is a security problem. If there is no "padlock" when you are about to use your password or credit card, then I would recommend that you should do your shopping somewhere else.

Some quick advice to site administrators:

• Avoid using absolute URLs on the form https://www.example.com/foo . Only use this kind of URL when you are intentionally changing to HTTPS or HTTP from a page that was loaded using the other protocol, or if you want to use that specific protocol.
• Instead, use relative URLs:
  
  - Use "/foo" if the content is on the same server, or just "foo" if it has the same folder path as the current document.
  
  - Use "//www.otherexample.com/bar" (note the two leading "/"s) if you are referencing content on a different server. All modern web browsers recognize this form of URL, and will automatically prepend "http:" is the document has a http-URL, and "https:" if the document has a https-URL. Example using "//tools.ietf.org/html/rfc3986#section-4.2"

This will ensure that you do not accidentally change from HTTPS to HTTP for some content, in particular when parts of the template for the webpage are also used on a HTTP page.