In related news, the Certificate Authority Security Council have today posted my article "An Introduction to OCSP Multi-Stapling".
Posts tagged with "TLS"
In related news, the Certificate Authority Security Council have today posted my article "An Introduction to OCSP Multi-Stapling".
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.
Is the server patched for the so-called "Renego" (CVE-2009-3555) issue?
If it is not patched, is it definitely vulnerable to the full Renego attack, or not? As readers who follow my articles will know, I have been following this topic for the past three years, since it was discovered, and been using the TLS Prober to track the patch coverage. If the server is fully vulnerable to this issue, an attacker can trick the server into performing actions using the user's credentials (an early proof of concept was to make the user post his twitter password to the twitter stream), and even if the server is not obviously vulnerable, there might be special circumstances under which it could become vulnerable, which is why the issue must be patched completely, not just pseudo-patched with a temporary workaround.
In this survey the Norwegian Renego patch coverage is markedly lower than in the international shops, only 52% were patched, compared to 77% in the international sites and 75% in the general population (as of December 2012). At present, in general a rather high fraction (57%) of the unpatched sites are also vulnerable to the Renego attack, and the number of unpatched and vulnerable sites in this survey are not very different from that number.
Does the server support SSL v2 and/or 40/56 bit "US-exportable" encryption?
While modern browsers do not support any of these methods (SSL v2 was replaced by SSL v3 in 1996, "exportable" encryption became demonstrably unsecure in early 1999), there is an extensive number of servers that are configured to use them, even if it is no longer needed. The only "real" scenario where support for these could be of use, is if your site is catering to users of Netscape 1 and MSIE 2 (SSLv2) or the international versions of Netscape 4 and MSIE 4 (weak crypto), and I seriously doubt that anyone are really doing that, considering all the concern about "having" to support much more recent browser versions. Even though these methods are not supported by modern versions of browsers, older versions of the browsers (e.g Opera 7) with support enabled, might still be in use, and if so, these old methods are so weak that it is reasonable to assume that than an attacker can easily downgrade the security of connection so that it will use the weaker methods.
There was a marked difference in this area between the Norwegian sites and the international sites, with a much higher number of Norwegian sites (46%) supporting SSL v2 than among the international sites (13%), and in fact the Norwegian count was slightly higher than the general support of SSL v2 (40%).
For weak crypto the differences were less marked, with Norwegians at 36%, internationals at 29%, both much lower than the general support of 47%. However, when combining the numbers for sites with weak crypto and/or SSL v2, there is a very large difference between the Norwegian sites (54%) and international sites (30%), both below the general support of 65%.
Website grading system
As there are many components of such a survey, to make evaluation of all the security aspects easier I have developed an A-F grading system for how sites use encryption. This system was first used in my Norwegian article two weeks ago.
The grades are defined as follows:
A: The entire shop is encrypted, Renego patched, no weak encryption.
B: The entire shop is encrypted, Renego patched
C: All of registration, login and checkout are encrypted, Renego patched
D: All of registration, login and checkout are encrypted, not vulnerable to the Renego attack
E: At least one of registration, login and checkout are encrypted, not vulnerable to the Renego attack
F: No encryption, or vulnerable use of resources, or Renego vulnerable.
A B C D E F C+D E+F Norwegian 0,0% 1,5% 16,2% 11,8% 10,3% 60,3% 27,9% 70,6% International 0,0% 0,0% 38,2% 7,4% 25,0% 29,4% 45,6% 54,4%
As can be seen from the table above, and the graph, there is a huge difference between the Norwegian sites and the international sites concerning how well they use encryption, with far fewer Norwegian than international sites using encryption properly, and far more using encryption improperly.
However, while the number of Norwegian sites with complete lack of proper encryption was much higher than for the international sites, in one area the Norwegian sites seems to be a step ahead of the their international competitors: Five of the sites were using encryption for the entire site, although most of them unfortunately came up short for one or more of the other points I was considering when grading sites (usually Renego), and ended up with a "D"-grade, or lower.
However, even though the international sites' usage of encryption is better than the Norwegian sites' usage, there is still a very large segment of international sites (54%) that uses encryption improperly, so it might be useful to look at these in more detail:
- Almost half of those (rated E, 25% of total) are using encryption properly for only one or two of the three main tasks that have to be secured.
- Among the sites rated F (29% of total), 45% were Renego vulnerable, 70% were using no encryption or improper encryption. The corresponding numbers for Norwegian sites were 29% and 73%.
These numbers indicate that while a lot of Norwegian sites need to significantly improve their use of encryption, there are many international sites that have to do so, as well.
A big question raised by this information is why are so many shopping sites using poor encryption? The answer will likely vary between sites, and what they tried to do, but here are some guesses:
Sites that use no encryption for some or all of the tasks
Didn't think of it
Don't need encryption
At least here in Europe these sites may actually be skirting the law, if not actually breaking it. In Norway the laws protecting personal information require encryption whenever "protection-worthy" personal information is being processed, which should definitely include purchasing history and payment details.
Concerned about performance
If it ever was a valid issue, the SSL/TLS performance concern has long since been debunked for properly configured systems. When Google moved GMail entirely over to HTTPS Google reported that they did not deploy any new servers, and that the HTTPS related activity was less than 1% of the CPU load on the servers.
Sites that use encryption submitting the information, but not for the page with the form
But, but, ... The information is sent securely!
If the page collecting the information is not encrypted, it does not matter at all if the password or payment information is sent securely, because the lack of encryption gives the attacker free hands change the page so that it also sends the collected information to the attacker before it is sent to the website.
Sites that use secure pop-ups for entering the information, on an unsecure page
The pop-up frame is secure, and it protects your information
Unfortunately, that is not true, because the user cannot tell that the frame is secure. Just like in the case above, as long as the containing page is unencrypted, the attacker can make the page do anything needed to obtain a copy of the submitted information, including replacing the "secure" frame with his own hijacked variation that will forward a copy of the information to the attacker.
Sites that use secure pages, but security is compromised by mixed content
Ooops! Sorry! Will fix it. <Sound of feet running in the direction of the web server>
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.
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
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]
I do not have any public opinions about this site, or the various controversies surrounding the site and its owner, but given the pre-launch emphasis on security and privacy, I decided to take a look at the site using the TLS Prober, to see how it measured up on the points that the TLS Prober checks, as well as a couple of other checks. I did not test the site's other security features, but Lee Hutchinson at Ars Technica already tested some of them.
Based on the results from the two servers I tested (the main site and the EU static server), the servers seem to be mostly standards compliant, and the main site actually supports TLS 1.2 .
Unfortunately, I still found some issues:
- The main site server is NOT patched for the TLS Renego issue! Almost three (3) years after the IETF TLS Working Group published the Renego patch (RFC 5746>, installing a new server that supports TLS 1.2, but is not patched for the Renego issue, does not look good, particularly when you are trumpeting the security of the site services. The server does not accept client-initiated renegotiation, so the server does not appear to be vulnerable to the full Renego attack, but there is no way to know if there is a back door that is vulnerable. (The static server is patched, but it only supports TLS 1.0, not TLS 1.2)
- The only encryption method (cipher suite) supported by the tested servers is RC4 with MD5. There are a number of people -- and I am one of them -- that are skeptical to using this particular cipher suite, as the MD5 method is severely weakened. At Opera, I did at times try to disable this cipher suite in Opera, but since 0.18% of servers, including some banks might break, it has not been practical to do so. I am sure that the server administrators chose this particular method because it is faster than the other methods available, but there is another cipher suite that is almost as fast (and also invulnerable to the BEAST attack): RC4 with SHA-1.
- While the main site uses a 2048 bit RSA key, the static site uses a 1024 bit RSA key. Given that 1024 bit RSA is to be phased out completely from CA issued certificates by the end of 2013, using that key size is not a good idea.
- The static server has SSL v2 enabled, and does accept and answer connections using SSL v2 (rather than displaying a "not allowed access" message that some servers do). As I have said before, SSL v2 is old, and it is unsecure. Additionally, no SSL/TLS-capable browser client published in the past 16-17 years has only supported SSL v2.
- The static server's certificate is not properly configured, as it is missing an intermediate CA certificate, and "assumes" that the client either knows the certificate or can fetch it.
- The main server's certificate is also not properly configured. It contains 3 extra certificates, in addition to the site certificate and the above mentioned intermediate. The extra certificates are probably unnecessary, since all modern clients ship with the Root certificate that issued the intermediate certificate (and the static server's configuration assumes knowledge about the intermediate and, implicitly, the issuing Root), the result is that the server sends a couple of kilobytes of unnecessary data in each full TLS handshake. The certificates are also not ordered properly.
- The static site apparently does not support TLS Session Resume, despite sending resumable sessions, which significantly increases the load on this server. I suspect that the reason session resume is apparently not supported is that the servers hosting the site are not sharing session information, as this server also supports the new Session Ticket extension used to store session information on the client, and does resume such sessions. The main site did resume normal sessions, but it did not support Session Tickets.
Do these issues, by themselves, make the sites unsecure? The answer is "not really", since none of the problems are critical. However, from the outside, there is no way to be sure that the TLS renegotiation functionality is completely locked down, which is a problem, since the Renego attack allows the attacker to choose the URL; so, if renegotiation is enabled for some areas of the site, these URLs could be abused by an attacker.
I would still recommend that the administrators of Mr. Dot Com's servers fix the above issues as quickly as possible.
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.
- The Public Suffix definition draft, introduced in this article. This version is substantially rewritten compared to earlier versions. Document link.
- TLS Multiple OCSP Stapling, introduced in this article. This version has some updates, drawing on implementation experience. Document link.
- Cache Context: how to organize resources in groups so that when you log out of a site the old pages cannot be displayed. Introduced here. Document link.
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:
- Explore the shop and its selection of goods.
- Select the goods you want to buy.
- Check what is in your shopping cart.
- Register if you are a new customer. (Or, if you are already a customer, proceed to activity #5)
- Log in if you are already a customer.
- Go to the checkout area with your shopping cart.
- Enter shipping details.
- 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.
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.
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.
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:
- Undersøke vareutvalget
- Velge varene man vil kjøpe
- Sjekke hva som er i handlevognen
- Registrere seg som kunde, eller
- Logge inn dersom man allerede er kunde
- Gå til kassen med handlevognen
- Oppgi hvordan varene skal leveres
- 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.
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.
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.
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.
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.
- 14 of the sites provided default secure sign up and login pages, but 3 included unsecure external Javscript, another two used mixed security content.
- 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 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.
- 2 others included mixed security content.
- (and one did not provide any security, at all).
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.
One of the preliminary steps before adding the renegotiation tests was to add support for testing SSL Session Resume, as that was needed to test some of the renegotiation corners I was planning to look into.
The Sessions feature in the SSL/TLS protocol has been in the protocol since SSL v2, and it allows multiple connections to use the same negotiated secret key data to calculate encryption keys for the connection, instead of performing a full negotiation to determined the encryption keys. This allows a secure connection to be established very quickly with no loss of security, since they are just reusing data they have exchanged earlier in a secure fashion during the previous full handshake.
Since the server-side part of full negotiation is very costly, due to how much CPU power is needed to decrypt the secret data from the client with the server's private RSA key (a cost that is being quadrupled with the ongoing transition to 2048 bit RSA keys), being able to reuse this key data in more than one connection is very valuable. It allows the server to do other things, like serving content or handling more individual users. Some sites split this cost between a SSL front-end server and an ordinary HTTP back end.
The lifetime of a session varies, depending on the server's capacity to store such sessions securely. The general recommendation is up to 24 hours, but just keeping a session for a few hours can have a great effect on the efficiency of a server.
For a single server, sessions are easy to deploy, but it gets more challenging when many servers are hosting the same secure site, since the information for each session has to be known to all the other servers hosting the site. All of this is part of the configuration system for the server.
The TLSProber is not the only tool that has investigated how well session resumption is used. Ivan Ristic has also done so, and our numbers match his findings: About 90% of websites resume sessions, 10% do not, evenly divided among sites that have disabled sessions completely and sites that just do not resume sessions.
However, given the results of our recent investigation into the Renego patch status for popular sites (popular sites are less likely to patch), and in part prompted by a discussion in a W3C WebID Incubator session at the recent W3C Federated Social Web Workshop in Berlin, I decided to look at how the numbers for no session resume support were for popular sites.
As you can see from the above graph, of the secure servers we probed 29% (860 of 2957) of the servers hosted by the Top 100 sites do not resume sessions, compared to only 8.6% for the non-Alexa rated sites.
Among the sites with servers in this category are:
- Twitter's search and mobile servers
It is a bit difficult to tell exactly how the servers in question are used by the sites, but given the number of servers, I think it is likely that many are heavily used by customers.
What are the consequences of not having session resume enabled on a SSL/TLS server?
When a server always refuses to resume a session, this will negatively affect the speed of a client that opens multiple connections to the server, because it (at least in Opera) will delay all the other connections to the server that it is establishing at the same time. The new connections are held back because the result of a full negotiation will affect all of them, and they need to know the new session identifier before they can continue. If a server never resumes a session, webpages loaded from the server will load more slowly than they could have, because new connections take longer to establish. Even if they could be opened in parallel, setting them up will take longer.
If a client on a given day only connects once (a single connection) to a site, session resume would not really improve server performance, in fact it would just require more internal bookkeeping.
If the client establishes more than one connection to the site on a given day, particularly within a short period like when loading a webpage with images, the situation changes depending somewhat on what the server produces and how heavy its normal workload is compared to the cost of the SSL/TLS handshake.
If the normal cost of work with a connection (w) is 1/100 of cost of the RSA handshake, and the server is handling both negotiation and responses, I estimate that 10 connections from a single client would roughly increase the load on the server 9-fold; 100 connections increases it 50-fold. If the difference in CPU usage between the two operations becomes even larger, the extra load on the server increases even more, becoming closer to the number of connections
established by the client within a time period.
On the other hand, if the normal cost of work on a connection is the same as for the RSA handshake, or higher (w>=1), then the load on the server at most doubles, no matter how many connections the client establishes, because the handshake is no longer the largest CPU cost factor. However, a website that fits this profile should probably investigate its code to discover if there are undiscovered bottlenecks that reduce performance or better ways to perform the server's tasks.
If the SSL handshake is handled by a front end, then the increased workload on the front end will follow the number of connections per client, and it will be 10-fold for 10 connections per client, 100-fold if 100 connections are used by the client in the period a session would be valid.
Given that, in many cases, the handshake is the most costly operation, this means that not having session resume significantly increases the load on your servers, almost linearly in proportion to the average number of connection each client will establish with the server in a given time frame.
The upper load limit depends on the relative difference between the handshake cost and the other operations of the site. For normal operations (w at most 10% of the handshake cost, between 10 and 100 connections) my calculations indicate that this upper limit is probably in the range of 5 to 50 times the load of using session resume.
In other words, according to my estimates, if you disable session resume for a heavily trafficked, secure site it is very likely that you must install 5-50 times (or more, depending on site profile) the number of servers you would have needed if you had used session resume.
This quickly snowballs into a considerably higher need for electric power, maintenance personnel, server rooms, capital requirements, and so on, ultimately reducing the site's profitability and the ability to work on new inventive features of the site. And then we haven't even considered the new consideration many people want to include: the impact on the environment. Unless I am mistaken, there is one big winner when you disable session resume: the server hardware vendor. (Also, the electricity company and the landlord are probably delighted, as well.)
SSL/TLS have always had a reputation for being very costly compared to not using encryption, although that has previously been debunked by Bob Lord, as well as by Adam Langley of Google. However, given the above, I find myself wondering if part of that reputation comes from not having used all the possibilities for optimization that exist in the protocol.
The Handshake operation is no longer prohibitively expensive due to advances in CPU architectures, but it is very likely still the most expensive single operation in a single transaction with the client. It is also an operation that does not have to be done frequently for each client; once every few (3-24) hours is frequently enough for most purposes.
So, if a popular and secure website seems to take a long time to load, the reason might not be (just) that it is popular, it might be that the site is not optimized correctly. It might be that the site administrator found it easier to throw money at the performance problem, rather than investigating more closely to discover what the bottleneck really was, and how it might be possible to solve the issue without more hardware.
- Apache 2.2 Session cache
The estimate of extra work load when not using session resume is calculated as follows:
- L : Load for all connections with no session resume, compared to using session resume
- N : Number of connections per client
- R : CPU cost of doing full handshake
- C : CPU cost for the entire connection (includes connection key calculation)
L(N,R,C) = N*(R+C)/(R+N*C)
If we eliminate the absolute CPU costs and set
w = C/R(the relative work for a connection compared to the RSA operation) we get:
L(N,w) = N(1+w)/(1+N*w)
The fraction of CPU power used for the handshake is as follows
F(Session resume) = 1/(1+N*w) F(no session resume) = 1/(1+w)
As an example, Adam Langley of Google has stated that their All-SSL sites, which support session resume, only consume 1% CPU for SSL handshakes.
Assuming that a user will be connecting to the server 400 times or more in a session (not really a large number if a user is processing a lot of email in Gmail, for example), this could be equivalent to 50 or more documents loaded with full pipelining in Opera.
Based on this, I estimate that the Google services per connection cost is 25% of a full handshake, if the number of connections per client is increased to 1000 the cost per connection is lowered to 10%.
|April 2013June 2013|