Yngve Nysæter Pettersen

Posts tagged with "encryption"

The state of encryption usage in online shopping

Thursday, April 18, 2013 9:37:14 AM

TLS, encryption, weak encryption, SSL ...

Last year I wrote about how Norwegian online shopping sites seemed to be using less encryption than international online shopping sites.

As I said in that article, given that it is difficult or impossible for a customer to discover how well an online shopping site will protect your information and privacy, proper use of encryption is one of the few indicators available to customer of how seriously the shopping site take their customer's security and privacy.

Unfortunately, all-encryption is not a full-fledged, perfect indication of good security; a shiny exterior can still hide a fairly insecure system, in which case the first indication a customer might have that something is wrong will be big headlines in newspapers about how a "big site lost X million passwords and personal details to attackers", at which time it is too late to do anything.

On the other hand, lack of proper use of encryption is a definite indication that the site does not take your security and privacy seriously, because, as secure as the system might be under the hood, if encryption is not properly used to secure access to the site, none of that security will matter since the front-door will be wide open to the attackers.

This year I have repeated the survey, increasing the number of sites to 68 Norwegian and 68 international sites. In both categories the majority of the sites are from big brands in their national markets. Most of the international sites are American, but there are number of European sites, as well.

As part of the survey, I checked the following:

Was encryption used properly for customer registration, login and checkout?

I define "Proper use of encryption" as follows: the entire login process was performed on a page loaded completely from a secure server. For example, submitting the details "securely" from an unencrypted page, or opening a "secure" frame/pop-up inside an unsecure page cannot be considered proper use of encryption. There were a few cases that used some kind of (probably JavaScript) redirection that caused Opera to show such pages as unsecure before I manually reloaded the page, which after giving the issue some consideration I decided to classify as secure. Please note that I did not check the payment systems or post-login systems of any of these sites.

Is the entire shopping site encrypted?

This can actually be rather difficult to determine accurately, since there can be localized bugs or configuration issues that causes the website leave the secure area. I have noticed this in at least two cases that I have investigated recently.

Is the server patched for the so-called "Renego" (CVE-2009-3555) issue?

If it is not patched, is it definitely vulnerable to the full Renego attack, or not? As readers who follow my articles will know, I have been following this topic for the past three years, since it was discovered, and been using the TLS Prober to track the patch coverage. If the server is fully vulnerable to this issue, an attacker can trick the server into performing actions using the user's credentials (an early proof of concept was to make the user post his twitter password to the twitter stream), and even if the server is not obviously vulnerable, there might be special circumstances under which it could become vulnerable, which is why the issue must be patched completely, not just pseudo-patched with a temporary workaround.

In this survey the Norwegian Renego patch coverage is markedly lower than in the international shops, only 52% were patched, compared to 77% in the international sites and 75% in the general population (as of December 2012). At present, in general a rather high fraction (57%) of the unpatched sites are also vulnerable to the Renego attack, and the number of unpatched and vulnerable sites in this survey are not very different from that number.

Does the server support SSL v2 and/or 40/56 bit "US-exportable" encryption?

While modern browsers do not support any of these methods (SSL v2 was replaced by SSL v3 in 1996, "exportable" encryption became demonstrably unsecure in early 1999), there is an extensive number of servers that are configured to use them, even if it is no longer needed. The only "real" scenario where support for these could be of use, is if your site is catering to users of Netscape 1 and MSIE 2 (SSLv2) or the international versions of Netscape 4 and MSIE 4 (weak crypto), and I seriously doubt that anyone are really doing that, considering all the concern about "having" to support much more recent browser versions. Even though these methods are not supported by modern versions of browsers, older versions of the browsers (e.g Opera 7) with support enabled, might still be in use, and if so, these old methods are so weak that it is reasonable to assume that than an attacker can easily downgrade the security of connection so that it will use the weaker methods.

There was a marked difference in this area between the Norwegian sites and the international sites, with a much higher number of Norwegian sites (46%) supporting SSL v2 than among the international sites (13%), and in fact the Norwegian count was slightly higher than the general support of SSL v2 (40%).

For weak crypto the differences were less marked, with Norwegians at 36%, internationals at 29%, both much lower than the general support of 47%. However, when combining the numbers for sites with weak crypto and/or SSL v2, there is a very large difference between the Norwegian sites (54%) and international sites (30%), both below the general support of 65%.

Website grading system

As there are many components of such a survey, to make evaluation of all the security aspects easier I have developed an A-F grading system for how sites use encryption. This system was first used in my Norwegian article two weeks ago.

The grades are defined as follows:

A: The entire shop is encrypted, Renego patched, no weak encryption.
B: The entire shop is encrypted, Renego patched
C: All of registration, login and checkout are encrypted, Renego patched
D: All of registration, login and checkout are encrypted, not vulnerable to the Renego attack
E: At least one of registration, login and checkout are encrypted, not vulnerable to the Renego attack
F: No encryption, or vulnerable use of resources, or Renego vulnerable.

                 A       B        C       D       E       F        C+D     E+F
Norwegian       0,0%    1,5%    16,2%   11,8%   10,3%   60,3%     27,9%   70,6%
International   0,0%    0,0%    38,2%    7,4%   25,0%   29,4%     45,6%   54,4%

As can be seen from the table above, and the graph, there is a huge difference between the Norwegian sites and the international sites concerning how well they use encryption, with far fewer Norwegian than international sites using encryption properly, and far more using encryption improperly.

However, while the number of Norwegian sites with complete lack of proper encryption was much higher than for the international sites, in one area the Norwegian sites seems to be a step ahead of the their international competitors: Five of the sites were using encryption for the entire site, although most of them unfortunately came up short for one or more of the other points I was considering when grading sites (usually Renego), and ended up with a "D"-grade, or lower.

However, even though the international sites' usage of encryption is better than the Norwegian sites' usage, there is still a very large segment of international sites (54%) that uses encryption improperly, so it might be useful to look at these in more detail:

Almost half of those (rated E, 25% of total) are using encryption properly for only one or two of the three main tasks that have to be secured.
Among the sites rated F (29% of total), 45% were Renego vulnerable, 70% were using no encryption or improper encryption. The corresponding numbers for Norwegian sites were 29% and 73%.

These numbers indicate that while a lot of Norwegian sites need to significantly improve their use of encryption, there are many international sites that have to do so, as well.

A big question raised by this information is why are so many shopping sites using poor encryption? The answer will likely vary between sites, and what they tried to do, but here are some guesses:

Sites that use no encryption for some or all of the tasks

Didn't think of it

Don't need encryption

At least here in Europe these sites may actually be skirting the law, if not actually breaking it. In Norway the laws protecting personal information require encryption whenever "protection-worthy" personal information is being processed, which should definitely include purchasing history and payment details.

Concerned about performance

If it ever was a valid issue, the SSL/TLS performance concern has long since been debunked for properly configured systems. When Google moved GMail entirely over to HTTPS Google reported that they did not deploy any new servers, and that the HTTPS related activity was less than 1% of the CPU load on the servers.

Sites that use encryption submitting the information, but not for the page with the form

But, but, ... The information is sent securely!

If the page collecting the information is not encrypted, it does not matter at all if the password or payment information is sent securely, because the lack of encryption gives the attacker free hands change the page so that it also sends the collected information to the attacker before it is sent to the website.

Sites that use secure pop-ups for entering the information, on an unsecure page

The pop-up frame is secure, and it protects your information

Unfortunately, that is not true, because the user cannot tell that the frame is secure. Just like in the case above, as long as the containing page is unencrypted, the attacker can make the page do anything needed to obtain a copy of the submitted information, including replacing the "secure" frame with his own hijacked variation that will forward a copy of the information to the attacker.

Sites that use secure pages, but security is compromised by mixed content

Ooops! Sorry! Will fix it. <Sound of feet running in the direction of the web server>

In many of the cases when pages use mixed encryption, the cause of the problem turns out to be third-party resources, advertisements and APIs, in particular external JavaScript APIs (which compromises the page's security completely). Whether true, or not, it often seems as if the third-party code have previously been used on unsecure pages and just copied to the secure pages, thus breaking their security. The vendors of such JavaScript APIs need to update their instructions, and change the recipes so that the website administrator never specify the protocol to use, and making the URLs look like this: "//www.example.com/scripturl.js". This is supported by all modern browsers and will automatically create a http URL when the containing page is served over HTTP, and a https URL when it is served over HTTPS.

Other causes

Of course, the is one other possible reason for this state of affairs: The customers, in large parts, let the online stores get away with not protecting their security and personal information. One can argue endlessly about whether this is caused by lack of knowledge about the risks, not caring at all, or that they just want to complete the transaction immediately, or if it is caused by any number of other reasons.

There is only one countermeasure for this kind of problem: Raising awareness, both to educate customers, and to point out to the online stores that they need to improve their security. One such initiative is x509labs, but the best signal to the stores require customers to start taking their own security and privacy seriously, and vote with their wallets.

No comments

How secure is online shopping, really?

Friday, March 2, 2012 4:45:20 PM

Extended Validation, TLS, Security, encryption ...

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

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.

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.

2 comments

Hvor sikker er egentlig norsk netthandel?

Tuesday, February 14, 2012 10:13:50 AM

Extended Validation, TLS, Security, encryption ...

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

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

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

Sikkerhet i nettbutikker

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

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

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

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

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

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

Bruk av kryptering i nettbutikker

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

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.

Sertifiseringsordninger

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

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

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

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

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

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

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

Oppsummering

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

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

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

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

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

No comments

Secure e-book shopping for the holidays? Maybe, Maybe not

Tuesday, December 20, 2011 5:44:20 PM

TLS, encryption, e-books, weak encryption ...

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.

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.

2 comments

Is it time to block unsecured content in "secure" documents?

Thursday, July 8, 2010 3:21:58 PM

Opera, browsers, banks, padlock ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Previous articles on this topic:

6 comments

"Nobody checks the padlock" debunked by Opera users

Friday, June 27, 2008 1:53:06 PM

CRL, Opera, browsers, SSL ...

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

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

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

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

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

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

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

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

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

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

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

What can be done about this?

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

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

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

15 comments

Lowering the EV bar

Friday, May 23, 2008 2:48:32 PM

Opera, SSL, standards, Extended Validation ...

Last week at the W3C's Web Security Context Working Group's meeting at Opera HQ here in Oslo we discussed what should be the criteria for displaying the Extended Validation (EV) indicator, or the Augmented Assurance (AA) indicator, as the WG has decided to call this technology.

As I have said earlier, we are of the opinion that the EV indicator should not be displayed unless all content is loaded from EV servers.

The opposing view is that, so long as all content is loaded over secure connections, the displayed document is what the author of the main document intended (bugs, vulnerabilities, and all), and that it is therefore only necessary to verify that the main document is served from an EV server, as this will provide the information necessary to identify the author.

The decision of the WG was in favour of the less restrictive position: if an AA/EV document loads all resources over strongly TLS-protected connections, then the document can be displayed with an AA/EV indicator.

In the interest of providing a common user experience with respect to EV we have decided to follow this recommendation, and today's Kestrel snapshot include this policy change.

We have, however, left the old logic in place, controlled by a preference that can be updated remotely. This permits us to quickly change to a stricter mode if the consensus about what constitutes an AA/EV site changes in the future.

As a consequence of this policy change a large number of sites, such as Paypal, with mixed EV and non-EV content will now get the "Green Bar" in Opera:

11 comments

New^W NOT in Kestrel #4: As many warnings about unknown certificate issuers

Friday, December 21, 2007 3:18:36 PM

Opera, browsers, SSL, standards ...

One of the most important parts of SSL/TLS, as it is used in browsers, is the use of certificates to identify the website you are visiting, and to identify the keys used to agree on the encryption keys used for the connection.

The certificate is the website's passport, and like a passport it is issued by an authority trusted by the people checking them. For passports this is the government of a country, for certificates it is a trusted Certificate Authority (CA).

As with passports, there are a lot of things that have to be checked to make sure the certificate is not forged.

Each certificate contain, among other things the name of who the certificate is issued to (the website); the public key of the website; who issued it (the CA); and a digital signature of the data in the certificate, which is signed by the CA.

To verify the signature the browser must use the public key of the CA to decrypt the signature (which could only be created by using the associated private key), and compare the result with the calculated "checksum" of the certificate. The public key is stored in another certificate issued to the CA - the CA certificate.

There are two types of CA certificates, the ones that are signed by yet another CA, called Intermediate CA certificates, and certificates signed by the CA itself, which are known as the Root Certificates or Self Signed Certificates.

The Intermediates CA certificates are verified using the public key of the signing CA, while the Root CA certificates are verified using the public key in the certificate itself.

The Root CA certificate is a special case. By itself it only verifies that somebody claiming to be the named issuer issued the Root Certificate, and by extension vouches for the named identity in the certificates issued from it. But that does not carry any real assurances.

To be sure that the Root CA is valid the signature on the certificate have to be verified by a trusted copy of the Root Certificate, stored in the client's list of such certificates. These certificates are usually shipped with the client, and are accepted and trusted by the vendor to be reasonably careful about who they issue certificates to and how they store the private key. The user can elect to not trust some of these roots, and may add his own list of certificates.

Only a certificate and its associated certificate chain that can be verified and traced back to a Root in the Trusted Root store on the client is accepted automatically. If a certificate cannot be verified because the signature does not validate this is a fatal error; if we can't trace the certificate to a known root we display a certificate warning.

A problem often encountered is that a web site gets a certificate from a CA that is issued from an Intermediate CA (Most CAs do this now, for convenience and security reasons, as well as for selling CA certificates to CAs without their own root or to cross-sign roots) but the web site administrator forgets to install the Intermediate CA certificate on the server. This means that the client will not be able to trace the certificate to a known Root, even if it has the Root in its repository, because clients usually do not, and are not expected to, know specific Intermediate CA certificates; the result (for the user) is an unexpected Unknown Issuer certificate warning.

SSL/TLS servers that do not send intermediate certificates are actually not operating in compliance with the SSL/TLS standard. The standard requires the server to send any CA certificates it cannot reasonably expect the client to have already, and the only thing it can expect the client to have is the root certificate, and not any intermediates.

There is however a mechanism (called Authority Information Access, AIA) defined in the specification of the certificate format that let the CA specify a "CA Issuer" download location for the Intermediate CA certificates. This mechanism is already used by at least one other browser (which neatly explains why so many badly configured sites get past testing), and now Opera 9.50 also use this mechansism.

When Opera 9.50 encounters a site with a certificate chain that is missing an Intermediate CA certificate linking it to the Root, but the certificate specifies an AIA issuer download location, Opera will download the specified certificate. If the verification then succeeds (without other incidents) to link the certificate with a known root, the certificate will be accepted as normal, and the intermediate CA certificate will be "cached" in the new Intermediate CA certificate store in Opera's certificate manager for future reference, to avoid downloading it again later.

What this means is that you will no longer get any certificate warnings about unknown CAs when the certificate is issued from a root and a CA that also includes an AIA issuer download location for the intermediate certificate(s) for the Intermediate CA(s) that issued the certificate.

Special thanks to Gary and Les in Verisign for helping me debug this new functionality.

1 comment

New^W NOT in Kestrel #3: As many warnings about weak temporary public keys

Monday, October 22, 2007 3:00:52 PM

Opera, Not In Kestrel, SSL, standards ...

The most important security pillar in SSL/TLS is the strength of the method used when agreeing on the encryption keys. If the method used for this is inherently weak, then it doesn't really matter how secure the rest of the encryption we are using really is.

The primary method used for this is the Public Key encryption methods, the most famous of which is RSA. These methods work by breaking the encryption key into two parts; one secret/private key and one public which is known by all (certificates are used to confirm who the public key belongs to). The relationship between these is that a message encrypted by one key can only be decrypted by the other. This means that anything encrypted with the private key can be read by everyone, but one will know that only the secret key could have created the message, and this property is used in digital signatures. Similarly a message encrypted with the public key can only be read using the private key to decrypt, and this is used in SSL/TLS to agree on the encryption keys used for the connection.

The security of this step depends on how difficult it is to break the encryption used to protect the encryption keys. For these methods breaking the private key means you can break all messages protected by it, and that when you have broken the key you can impersonate the owner. The difficulty of breaking an RSA key is generally determined by how long the key is. Given present technology, I estimate that the work doubles for every 25-30 bits that are added to the key length (as opposed to work doubling for every additional bit when attacking keys for a symmetric method, like AES). At present, 640 bit RSA keys have been broken in 5 months using less than 100 workstations, but even the commonly used 1024 bit keys are threatened now and are not recommended for messages that need to be secure past 2010. As a result, Opera will warn (and is the only browser that does) when these keys are shorter than 900 bits.

A way to make exposure of past messages more difficult is to change the key used to protect the messages very often. This means that there are more keys to break if you want access to all messages. With sufficiently strong private keys, massive attack becomes infeasible and even attacking a single key becomes impracticable.

In SSL/TLS these kind of rapidly changing keys are implemented using the Public Key method, also known as the Diffie-Hellman (DH) key agreement. The system most commonly works by having the server send a temporary (ephemeral) DH key (or DHE key) to the client, which then confirms the authenticity of the key by digitally signing it with its RSA key. The client then uses this DHE key to agree with the server on the encryption keys. Given that these keys are changed every few minutes there will be hundreds of keys used by a server every day, making the task of breaking the keys infeasible if the tasks take even a short time. But best of all, even if the RSA key of the site is broken, the attacker won't get the secret parts of the DHE keys. To be able to do this, they would have to break each key.

Given that the RSA and Diffie-Hellman algorithms are based on the same math, they are equally strong for a given key-size. This means that to provide the same level of security for a given connection as the RSA key, the DHE key has to be as long as the RSA keys. This is where an increasing number of secure servers fall short.

Both RSA and DHE secret key operations are very time consuming and therefore reduce the number of connections a server can handle. While most sites are using RSA keys that are sufficiently long, the fact that there are lots of DHE keys have led some vendors to mistakenly think that they can reduce the length of the DH keys so that more transactions can be performed. Most of these reduced keys are either 512 bits or 768 bits long (which Opera warns about), but I have actually seen servers sending 256(!) bit DHE keys (Hint: I estimate that these can be broken in minutes or hours).

What these vendors seem to forget is that not all attackers are interested in every transaction performed at a site. An attacker might just be interested in one individual visiting the site, and in such cases the size of the DHE key becomes significant. If the key is too short it may become economically feasible for the attacker to break the DHE key. This is why Opera also warns about weak DHE keys, which are shorter than 900 bits.

As reports about weak DHE keys seem to increase, I found it necessary to take a few steps to counter this problem.

The first step was to ask the TLS Work Group to specify clearer how these keys are created. In addition, specify what steps a client should take to ensure the DHE keys are adequately secure. This is currently being worked on for TLS 1.2.

The second step was to evaluate the size of the DHE key when we receive it. If the key is shorter than 1024 bits, we close down the connection after sending an Insufficient Security (71) fatal error to the server, and automatically try to establish a new connection where the DHE methods are listed as less preferred than they normally are. By doing this we will most likely be able to establish a sufficiently secure connection using the RSA-only methods instead. If the server still selects a DHE method, then a warning may be displayed if necessary. This extra round trip will usually not take extra time because it will be handled as part of our usual TLS feature testing of the server (watch this space for news about that). A known issue we are working to fix is that for mail servers where this dialog have been shown previously, this will not take effect until the second time you check email, and that the first attempt will fail.

The end result is that (normally) you will no longer see the weak public key warning, except if the site is using a weak key in the certificate. We can't do anything about the certificate keys because the size of that key is selected directly by the Webmaster. If you get any of those warnings, please notify the webmaster!

Further reading about crypto on Wikipedia:

Public Key Cryptography
RSA
Diffie-Hellman (DH)
SSL and TLS
About Keysizes

No comments

New^W NOT in Kestrel #2: "Export"-grade encryption is junk(ed)

Monday, October 8, 2007 2:48:50 PM

TLS, Security, Opera, encryption ...

SSL v2 is not the only old encryption capability that is no longer supported by Opera 9.5, also known as Kestrel. We have also removed support for 40 and 56-bit encryption. Like SSL v2 these methods have been disabled by default since v9.0

There are several reasons for this move:

40 and 56-bit encryption methods are "soooooooo" last century. These methods were defined as a way for US based browser vendors to be able to distribute their SSL enabled client outside the US. The reason this was necessary is that the US government and several allies defined (and I believe still define) encryption as a weapon, but it was possible to get permission to export software that only supported 40 bit encryption (and later 56 bit) and that included a couple of other restrictions (there was an exception for financial services). The reason for the limitations was, presumably, that the intelligence communities of these countries had the technology needed to break these keys. In 1999/2000 the restrictions were partially lifted, at least for mass market products like browsers and email clients.
40 and 56-bit methods are dismally weak given today's technology. In mid-1998 56-bit DES was broken in less than a 56 hours, this was reduced to 24 hours less than half a year later. Given today's technology I expect that the same can be done in less than 30 minutes with enough hardware. And 40-bit can probably be broken in less than a second. What this means is that these methods no longer provide any protection at all.
Any server that only supports these methods is more than 8 years old, which means the actual security of the server, even ignoring the lack of encryption strength, is .... questionable. To top it off, a number of Certificate Authorities sell "SGC" certificates that will permit most US produced and exported servers (and clients) to enable 128 bit encryption. These certificates were originally reserved financial institutions, but after the crypto export restrictions were lifted they have become available to all.

While I believe servers that only support 40/56 bit encryption are a bit more common, in absolute numbers (perhaps a few thousand), than SSL v2 servers, I can't remember hearing about any such sites for over a year, despite the fact the the methods have been disabled by default about that long in several browsers. That indicates that the servers are not visited by a lot of people, if any. I think it is time to signal quite clearly to the sites that may be left that the technology they are using is obsolete.

If you do encounter a "secure" site that require 40 or 56 bit encryption, what can you do? Well, I don't recommend it, but you can go back to Opera 9.2x and enable the weak ciphers. But before you do, perhaps you should ask the system administrator this question: "Why are you running the site with 8 year old software?"

6 comments

1 2 Next »