This cartoon appeared in the october 2011 issue of the IETF Journal and was inspired the broken Diginotar CA.
Remember my previous post on this topic. I went back to the postbank site to see if things had improved. Turns out they have not. Here is a screenshot from the page explaining the SecureCode. Its all about the footnote (the last line on this screenshot).
The last line reads:
Caution: When you click on this link you will be lead to a website that has no Postbank address. Check wether the address starts with https://postbank.arcot.com. With that you will have a safe connection to register your Secure code
I will not be repeating my argument that notifying, from a non-http- secured page, to a https page breaks users expectation (why would you trust postbank.arcot.com over of postbank.secure-bank-services.com). Instead, I want to highlight that if you click on the link that displays “https://postbank.arcot.com/” you actually get redirected via a non secured link like http://www.postbank.nl/ing/pp/page/external_link/redirect/0,3042,1859_180483_849292156,00.html?ExternalLinkId=849292156
Again, that is unnecessarily complex and confusing for users.
Controleer of het adres begint met https://postbank.arcot.com Hiermee heeft u een veilige verbinding om uw SecureCode te registreren.
Edit April 8, 2012: Clean-Up HTML code.
Remark April 8, 2012: While this is not common practice with any Dutch bank I know of I have seen this type of practice elsewhere.
Updated: Aug 22 to add that the Postbank now informs their users about the use of the arcot domain.
Updated: Aug 24, some slights textual edits.
Updated April 8, 2012: html code and moved pictures to a different location
Often people argue that DNS spoofing will not impact peoples ability to do banking and such. With the current practices both with user interfaces as well as the practices that the banks themselves deploy I claim that this is close to nonsense.
The basic attack is that user Alice wants to connect to her website: www.postbank.nl, in order to do a secure transaction the bank will redirect her to a secure website. If Alice is smart she will check the security of the connection by looking at the padlock and verifying if the domain she connects to make sense.
This is not going to work as long as:
The obvious DNS based attack is to redirect the unsecured postbank.nl site and provide link to postbank.malice.nl that have valid certificates. We all know that getting a certificate for postbank.malice.nl is a trivial matter, it takes an e-mail address and a credit card number.
Below is an example that banks take it for granted that users trust Arcot.com as a middle man for either Mastercard or the Postbank. And personally I have never heard of arcot.com, so what do I know.
The point I am making is that as long as Banks and Creditcard companies are implementing practices that make users get used to being redirected to completely unrelated, albeit HTTPS secured domains, they will not help to create a mindset where users will understand when they are subject to certain kinds of fraud, like phishing.
My experience today
Apparently there is some new mechanism introduced to secure Internet credit card payments. Its called MasterCard SecureCode. I did not know about this, but that may be because I have not seen the snail mail yet. I was introduced to this new protection mechanism to protect against fraud while trying to pay for a conference.
The original website redirected me to a site from tripledeal.com for the payment transaction. Even though the original website did not tell me that the transaction was to be handled by triple deal I decided to take the leap of confidence based on prior experience.
So far so good.
At the end of the payment process a new validation step is introduced: I am invited to go to my bank to validate the payment.
So pressing the “To Your Bank” button opens up a new window.
Oh… wait.
This screen asks me about details about my credit card. I need to be extra suspicious about entering information. Let me click on the padlock to verify that I am actually talking to my bank.
Oh.. so an organization called arcot.com is claiming to represent my bank? I do not believe that, anybody could be claiming to be my bank, even with that little padlock in place.
So, there is this new validation scheme I have never heard of, that needs some of my credentials, and that takes me to a site that does not seem to be my bank? What more do I need to suspect that I am subject of an elaborate phishing attack?
Let me read the page once more… Oh it says more information can be found at postbank.nl/SecureCode. So lets go there https://postbank.nl/SecureCode …. timeout. Let me try over a non secure channel and see what I get (depending on trailing/nontrailing slash).
So lets call the bank.
I called the Postbank’s creditcard helpdesk I got a perfect explanation about the introduction of the SecureCode technology. I explained that I got a pop-up from postbank.arcot.nl, was put on hold, and was then explained that dealing with Arcot was OK.
The fortunate point was that I did not need to explain that me dealing with arcot.com was in sharp contrast with the anti-phishing policies that the banks deploy, and that the postbank helpdesk person actually understood that the pop-up should have originated from a postbank.nl or maybe mastercard.com domain. But he had no way to escalate the problem and asked me to report in e-mail.
Time to write a mail. I plan to post the correspondence in a follow up.
Update Aug 22.
It seems something happened. The postbank website now mentions:
* Let op, als u hierop klikt wordt u naar een website geleid die geen Postbank adres heeft. Controleer of het adres begint methttps://postbank.arcot.com. Hiermee heeft u een veilige verbinding om uw SecureCode te registreren.
Which is basically a warning that you will be dealing with arcot.com and that that is OK.
This does partly address the problem
Who knows there will be a structural solution for this problem.
Today I upgraded, without any hesitation, my license for Curio that came with version 5 today.
I payed with Pay Pal and got a nice confirmation mail. Being a bit touchy about user interfaces and domain names (see my post earlier today) I post the following without comment.
I just read an article on ZDnet. It describes a demo of an exploit on an un-patched XP SP1 machine on an open wireless network. The MS executive was surprised by the ease of the attack.
Nick McGrath, head of platform strategy for Microsoft U.K., was surprised by the incident."In the demonstration we saw, it was both enlightening and frightening to witness the seeming ease of the attack on the (Windows) computer," said McGrath. "But the computer was new, not updated, and not patched."
The first sentence makes one wonder on which planet has this man been hiding. The second sentence makes me wonder how machines are sold other than new, not updated, and not patched.
Yesterday I presented a column at het Domeinnaamdebat 2006. It was intended to start a discussion on the use of IDN within the Dutch top-level-domain. Although I am very supportive of the IDN technology I do not think it is needed for functional use of web, mail, voip and all those other fine Internet protocols under the .NL domain. Introduction causes more pain than worth.
If .NL were to deploy IDN we should allow more than only the few characters that are currently recommended by SIDN. In one should introduce Arabic, Cyrillic, Chinese and other scripts too. The restrictions to the current character set are artificial and arbritrary.
The text is in Dutch, I actually needed to introduce a new locale into the blogging software in order to cut and paste the UTF8 based text. I hope all characters are presented properly on all browsers.
Ik ben gevraagd om de discussie over IDN met een column in te leiden. Ik noem mijzelf soms DNS protocolspecialist en een technische presentatie over Unicode, Nampeprep, stringprep en normalisatie zou dus voor de hand liggen. Dit wordt niet zo’n presentatie. Ik neem als uitgangspunt de aanbeveling van SIDN en stel hardop wat vragen. Ik chargeer zo nu en dan een beetje, het blijft tenslotte een column.
Veel protocollen op het Internet gaan uit van ‘hostnames’. Hostnames hebben de restrictie dat ze worden uitgedrukt door 26 Latijnse letters, 10 cijfers, en een streepje. De namen van webservers zijn ‘hostnames’, de namen aan de rechterzijde van het apenstaartje in een e-mail adres zijn ‘hostnames’. Hostnames zijn een deel verzameling der domeinnamen, maar dat is een technisch detail waar ik niet verder op in ga. Wordt niet verward doordat de termen domein en hostname door elkaar gebruikt worden.
Het International Domain Names, of IDN, protocol is uitgevonden om ‘hostnames’ weer te geven in een schrift dat afwijkt van 26 Latijnse letters, 10 cijfers en een streepje. Er zijn nogal wat schriften die afwijken van die beperkte karakterset; Japans, Chinees, Linear B, Zweeds, Russisch, &c, &c. IDN maakt het mogelijk om domeinnamen op in verschillende schriften te representeren en voorziet daarmee in een economisch behoefte. Niet voor de gebruikers van Linear-B maar voor Japans en Mandarijn des te meer.
IDN is een afspraak over hoe ingetypte tekst in een ‘vreemd’ schrift wordt omgezet naar tekens die mogen voorkomen in een ‘hostname’. Het definieert ook hoe de ‘hostname’ weer naar de oorspronkelijke set glyphen wordt terug getransformeerd. IDN wordt geïmplementeerd op applicatie niveau. Voor gebruikers van een applicatie zonder IDN ziet de domeinnaam er ook uit als een klassieke domeinnaam die de combinatie "xn--" en wat onbegrijpelijke letter combinaties bevat.
Men zou alle denkbare karakters kunnen toelaten. Dat is niet echt praktisch, het lijkt dus redelijk om keuzes te maken met betrekking tot het gebruik van de karaktersets. Die keuzes zijn commercieel, economisch en cultureel.
Ten eerste zullen we moeten kiezen welke schriften we gebruiken.
In haar aanbeveling stelt SIDN dat het zijn afbakening definieert ten behoeve van de Nederlandse Internet gemeenschap. Ik weet niet waar die Nederlandse Internet gemeenschap uit bestaat. Zijn dat de mensen die surfen naar Nederlandse domeinnamen, de mensen die een account hebben bij een Nederlandse provider, de mensen die in het Nederlands communiceren, de mensen die in Nederland zaken doen, de mensen met een Nederlands paspoort die zich op het Internet begeven? U begrijpt dat iedereen die zich aan een dergelijke definitie waagt een goed politicus moet zijn.
Uitgaande van de Nederlandse taal wordt er gekozen voor het ‘Latin’ schrift. Dat schrift bevat inderdaad alle karakters die we het Nederlands, het Frysk, het Haags en het Limburgs gebruiken. Het omvat zelfs karakters die in het Turks gebruikelijk zijn. Maar waar moet nou de islamitische slagerij om de hoek terecht? Kan hij zijn bedrijfsnaam registreren in het schrift wat zijn klanten appelleert: Arabisch. Mijn islamitische slagerij is ingeschreven in de kamer van koophandel, heeft een Nederlandse Internet provider, slacht Nederlandse geiten en is bovendien oud-Hollandsch goedkoop. Is hij geen deel van de Nederlandse Internet gemeenschap? Al is een keuze voor ‘Latin’ is niet geheel onlogisch, er wordt wel een culturele grens getrokken die misschien opgerekt moet worden. Wie neemt de verantwoording voor die keuze?
Als er dan al voor een bepaald schrift is gekozen, zijn we dan klaar voor de komende 10 jaar? Kan een toekomstige Europese richtlijn over het gebruik van schriften binnen de lidstaten worden uitgesloten? Het lijkt me geen slecht idee om als randvoorwaarde aan de invoering van IDN te stellen dat nieuwe schriften later kunnen worden ingevoerd.
Welke schriften, één of meer, we ook kiezen we kunnen een aantal karakters uitsluiten dankzij technische limitaties van het IDN protocol: geen spaties, samengestelde karakters, &c. Daarnaast worden de hoofdletters die de door IDN gedefinieerde transformatie niet overleven uitgesloten. Het ruimt lekker op en er is wat mij betreft weinig willekeur in deze keuze.
Niet technische keuzes komen weer om de hoek kijken als we de visueel verwarrende karakters uitsluiten. Die karakters worden in het Engels homoglyphen genoemd. Een Nederlandse variant van dit Latinisme heb ik niet kunnen achterhalen. Maar dat terzijde.
ICANN beveelt aan dat verschillende schriften niet door elkaar gebruikt mogen worden.
Dat de uitbaters van undutchables.nl daardoor hun merknaam niet als UИDUTÇABLΣS.nl onder kunnen registreren is jammer, maar we kunnen de schuld bij de ICANN aanbeveling leggen. Er moet wel tussen verschillende varianten van het Latin schrift worden gekozen, dat is een detail.
Blijft de angst dat er homoglyphen binnen een karakterset voorkomen. "paypal" en "pąypal" (geschreven met een ‘a’ met ‘ogonek’) lijken veel op elkaar. Dat verschil kan door booswichten wordt uitgebuit. Op basis van mogelijke verwarring en het niet aanwezig zijn van karakters in het Nederlands wordt in de aanbeveling van SIDN de hele "Extended Latin A" karakterset weggestreept. Sluiten we daardoor de Nederlandse Internet gebruiker uit? Ik weet het niet, ik weet immers niet wie die gebruiker is. Is de restrictie terecht, ook dat weet ik niet.
Met het uitsluiten van de ‘Extended Latin A’ karakters is de angst voor misbruik van homoglyphen niet uit de lucht. Daarom worden in de SIDN aanbeveling, mijns inziens volstrekt willekeurig, nog een aantal karakters weggegooid. Daaronder de ø, de o met de schuine streep. Dat maakt registratie van bløf.nl onmogelijk. Ik vraag me af of de leden van Bløf zich lid van de Nederlandse Internet gemeenschap voelen of niet. Ze zingen in ieder geval wel bloedmooie Nederlandse liedjes. Kunnen de leden van het ‘anhangerschap Normaal’ nu niet de domeinnaam ‘høken.nl’ registreren?
Ook de ï, een i met een trema, wordt weggemieterd. Dat is jammer want ‘goed-geïmplementeerd.nl’ zou ik zelf een interessante domeinnaam vinden. En waarom wordt een i met een trema wel gezien als homoglyph en een a met trema niet? Voor een nietsvermoedende surfer ziet "äbnamro.nl" er waarschijnlijk hetzelfde uit als "abnamro.nl". Als de gebruiker al naar de adresbalk van zijn browser kijkt. En waar blijft de "ç", de c met cedille? Waar moeten we heen met onze in het Turks geschreven namen (de schoolklas van mijn zoon zit er vol mee).
Over de adresbalk gesproken. IDN heeft alleen betrekking over wat er in een adresveld van een applicatie wordt ingetypt. Niet op de tekst in de browser, of in een e-mail.
Wie heeft er recent nog een domeinnaam in getypt in zijn adresbalk? Wie heeft er in één keer foutloos www.domeinnaamdebat2006.nl in zijn browser getypt en wie heeft er voor "domein debat .nl 2006" ge-googled?
Daarnaast vraag ik me af hoeveel mensen er weten hoe je een é, û of een ï moet typen? Heeft invoering van IDN wel nut als je bijna zeker weet dat een groot deel van de Nederlanders Café zonder accent aigu schrijft. Overleeft www.tête-à-tête.nl een radio commercial? Bovendien heeft die adres balk uiteindelijk weinig te maken met wat er in de browser wordt gepresenteerd.
Mijn islamitische slagerij heeft voor zijn Arabisch schrijvende klanten een link staan vanaf een portal voor Arabisch schrijvende Nederlanders. Ik kan die link gewoon volgen zonder dat ik een letter Arabisch in type. Een uurtje willekeurig rondklikken op sites die Japans schrift gebruiken kan ook erg opwindend zijn. Ik kan mijn IJslandse collega Guðmundsson gewoon correct adresseren door te clicken op een link in mijn adresboek. Mijn punt is dat ik een bepaald schrift niet in de adres balk hoeft te kunnen typen om in je eigen schrift te kunnen mailen en surfen. Die adresbalk is zo belangrijk niet.
Maar laten we dit nu eens allemaal terzijde schuiven en eens kijken naar de economische zijde van het verhaal.
Hoeveel gaat de invoering van IDN kosten? Een paar zaken die in ieder geval geld gaan kosten is de intergratie in de Whois Database,in de Whois clients, in het Billing systeem, in de systemen waarmede de leden met SIDN communiceren en in de systemen waarmee de leden zaken doen met hun klanten. Al deze systemen moeten zo gebouwd worden dat andere karakters op termijn moeten worden kunnen ingevoerd. Met andere woorden op bijna alle systemen moet IDN worden geïmplementeerd.
Juridische kosten gaan omhoog, ook al probeer je homoglyphen uit te sluiten je gaat te maken krijgen met homografen. Zijn "cafe-bluf" en "café-bløf" verschillende merken, betekenen ze hetzelfde? De invoering van meer variatie in het schrift zal leiden tot meer variatie in interpretatie en dus in hogere juridische rekeningen.
Stel we gaan al die kosten naar rato omslaan naar die enkele web site houder die IDN gaat gebruiken. Is de prijs van een domeinnaam dan nog wel reëel? Hoeveel betaald u voor "reëel.nl"? Gaan we er met zijn allen voor betalen? Is er een economische behoefte of gaat het alleen om het weergeven van beeldmerken in het adresveld van e-mail programma’s en browsers?
U begrijpt het van mij hoeft het niet zo nodig. Hebben we ons overigens al afgevraagd welk probleem we proberen op te lossen? Waarom we het in de eerste plaats over IDN hebben?
In a recent post on the SONY DRM Hell Bruce Schneier refers to a statistical analysis done by Dan Kaminsky.
Kaminsky asked more than 3 million DNS servers across the net whether they knew the addresses associated with the Sony rootkit — connected.sonymusic.com, updates.xcp-aurora.com and license.suncom2.com. He uses a "non-recursive DNS query" that allows him to peek into a server’s cache and find out if anyone else has asked that particular machine for those addresses recently.
The premissis is that all that query for these addresses are interested in downloading the patch. But later on in the article Schneier writes
In any case, Sony’s rapid fall from grace is a great example of the power of blogs; it’s been fifteen days since Mark Russinovich first posted about the rootkit. In that time the news spread like a firestorm, first through the blogs, then to the tech media, and then into the mainstream media.
In many of these blogs some of the above addresses are linked and it would not surprise me if blog-readers following these links are a significant fraction of the query sources.
The Feb 7 FWC.com article "Hashing out encription" first paragraph reads:
A little further down William Blurr, a NIST security guru is quoted:
So are we suprised by what appeared on Schneier’s Blog yesterday:
SHA-1 has been broken. Not a reduced-round version. Not a simplified version. The real thing.
The research team of Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu(mostly from Shandong University in China) have been quietlycirculating a paper announcing their results:
This attack builds on previous attacks on SHA-0 and SHA-1, and is amajor, major cryptanalytic result. It pretty much puts a bullet intoSHA-1 as a hash function for digital signatures (although it doesn’taffect applications such as HMAC where collisions aren’t important).
The paper isn’t generally available yet. At this point I can’t tellif the attack is real, but the paper looks good and this is a reputableresearch team.
More details when I have them.
The combination of the two messages makes one wonder doesn’t it.
Anyway, my main worry about all this has to do with DNSSEC that uses RSA/SHA1 based signatures.
I am not a cryptanalist and I confess I know far less than I would like to know on this subject but I figure that given the pre-defined structure of the material being hashed (a RRset wich contains well defined fields that can only have well defined vallues such as type codes) an exploit would take more than 2^33 ops. I need education… How many orders of magnitude does one gain by needing structure?