Implementer's notes

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

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

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

Sikkerhet i nettbutikker

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

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

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

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

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

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

Bruk av kryptering i nettbutikker

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

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

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

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

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

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

Resultatet av denne undersøkelsen er mildt sagt skuffende:

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

Hvorfor bruke kryptering?

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

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

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

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

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

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

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

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

Sertifiseringsordninger

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

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

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

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

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

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



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

Oppsummering

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

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

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

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

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

As mentioned in another of my TLSProber articles, we have constantly been adding functionality to the prober's engine.

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:

• Yahoo!
• Live.com
• Twitter's search and mobile servers
• MSN
• EBay

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.



References:

• Apache 2.2 Session cache

Appendix:

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%.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



Previous articles on this topic:

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

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

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

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

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

In the past couple of weeks I have seen a few reports that the American Express site https://online.americanexpress.com/ (Testurl) was using a revoked certificate. This site redirects to various American Express services.

As of this morning (October 1st) the problem has been fixed.

As I have mentioned before, a revoked certificate is no longer valid, and therefore no browser should give access to the site. In the worst-case scenario, a certificate is revoked because the key has been compromised, and the site is being used by criminals for fraudulent purposes. Revocation of a certificate is analogous to blacklisting of a credit card because the card can be abused.

The available (human readable) information indicates that the current situation was not a worst-case scenario. What seems to have happened is that American Express requested the current certificate in May, then shortly thereafter requested an updated certificate, possibly to correct a minor mistake. The old certificate is revoked automatically after a reissue, and the Web site is expected to use the newer certificate, but it seems that American Express for some reason did not update their server. Since there is no way for a browser to distinguish between a benign mistake and a worst-case scenario; we have to assume the worst.

I am sure somebody is going to mention that the site worked without problems in many other browsers. Yes, it did, but that was because the certificate for this site is issued from a special Verisign certificate hierarchy (which is being retired) that does not specify the revocation list (CRL) download location, so browsers cannot go looking for the information, based on the certificate. The reason why the CRL is not specified may, as I understand it, have to do with the fact that the hierarchy was never intended to be used for Web site certificates, but for authentication of dedicated secure server-to-server connections. Opera may be one of just a few browsers that actually check the CRL for this hierarchy, but we can only do this because we have added the certificate to a list of overrides our repository that specifies where to fetch the CRL, otherwise we would not show a padlock on these sites (and as we discovered last year, Opera users really do check the padlock!).

A partially unanswered question is why reports appeared only so recently. Part of the reason is that a bug in our rootstore repository server caused the CRL override Opera uses to be dropped for 6-8 weeks (we fixed that two weeks ago), but that does not explain why there are no reports before the end of July. My guess, based on information from Netcraft, is that online.americanexpress.com is a new server that was brought online just a few months ago, which turns out to be well into the period when most of the CRL overrides were disabled by the repository bug, which means we did not check the CRL either for this site during that period .

Once we learned of the problem, beginning of last week, we informed Verisign about it, and I assume they informed the American Express contact for this certificate about the problem.

Yet, more than a week later the revoked certificate was still being used by the Web site, until it finally got fixed last night. Frankly, I expected better from American Express.