Security - 4

If you don't know who I am and what I do, let me quickly introduce myself:

I live in Berlin and work as a freelance journalist. I sometimes write for the newspapers taz, the online version of the Zeit and I'm a regular author at the IT news magazine Golem.de. Currently, my main topics are IT security and cryptography. I cover those topics both for general interest media and for experts. I also write about some completely different topics like climate change, energy politics, science and problems in medicine and whatever I happen to find interesting. I maintain an extensive list of articles I wrote in the past on my website and just recently added an English version with Google Translate links to my articles.

A notable article I wrote lately was a large piece on the security of various encryption algorithms after the Snowden revelations which got around 900.000 visits. In the past days I covered the Heartbleed story extensively and am happy to say that I wrote the first article in German language that appeared on Google News.

I'm quite happy with my job right now. Especially my cooperation with Golem.de is going very well. I have enough topics to write about, have some new opportunities in sight and earn enough money from my work to pay my expenses However, all my current employers publish exclusively in German. I sometimes cover topics where I'd wish that I could target an international audience and where I'd like to publish in English language.

If you are working for any kind of media in English language and you think my work may be interesting for you: Please get in touch with me. Of course if you work for any kind of media in German language and think the same you may also get in touch with me.

I'm aware that this is difficult. Anyone who decides to cooperate with me on this needs to be aware: I'm no native speaker. I think my English language skills are decent, but they are far from perfect. My work probably requires more spell checking and editing than others.

Ich halte morgen (11.04.2014) einen Vortrag im Hackerspace AFRA in Berlin. Hier die Ankündigung:

Beliebte Webanwendungen und Content-Management-Systeme haben regelmäßig Sicherheitslücken. Nutzer müssen diese Anwendungen regelmäßig updaten, aber viele Betreiber von Webseiten sind sich dessen nicht bewusst. Im Rahmen des Betriebs von Servern mit einigen Hundert Kunden habe ich das Tool FreeWVS entwickelt, mit dem sich Webanwendungen mit bekannten Sicherheitslücken erkennen lassen. Wenn man Updates versäumt, tauchen fast zwangsweise irgendwann gehackte Webanwendungen auf. Diese aufzuspüren ist aber nicht unbedingt trivial. Wenn es zu spät ist, wird der eigene Server unter Umständen zur Spamschleuder oder wird für DDoS-Attacken missbraucht.

Beginn 20:00 Uhr, die AFRA befindet sich in der Herzbergstraße 55, nahe der Tram-Haltestelle Haltestelle Herzbergstraße/Siegfriedstraße.

Update: Die Slides gibt's hier als PDF, hier als Latex-Source und auf Slideshare.

Ich hatte ja vor einer Weile zu der Botnetz-Geschichte und dem BSI etwas geschrieben. Das BSI hatte im Januar die Möglichkeit angeboten, zu prüfen, ob die eigene Mailadresse sich in einem Datenbestand befindet, der offenbar bei der Analyse eines Botnetzes gefunden wurde. Ich hatte eine betroffene Mailadresse und fand die Information, dass irgendwo irgendein Account von mir offenbar gehackt wurde, reichlich unnütz und habe deshalb das BSI nach Bundesdatenschutzgesetz um weitere Auskünfte gebeten. Ich habe bisher noch nicht berichtet, wie das eigentlich weiterging.

Das BSI hatte mir daraufhin mitgeteilt, dass es selbst die Daten gar nicht besitzt. Vielmehr hätte man nur die Hashes der betroffenen Mailadressen gespeichert. Die vollständigen Daten lägen nur bei den zuständigen Strafverfolgungsbehörden vor. Welche das sind teilte man mir nicht mit, aber aufgrund von Medienberichten wusste ich, dass es sich um die Staatsanwaltschaft Verden handeln musste.

Also stellte ich eine erneute Anfrage an die Staatsanwaltschaft Verden. Diese teilte mir dann mit, was bereits in diesem Artikel bei Golem.de stand: Das Datenschutzgesetz greife nach Ansicht der Staatsanwaltschaft in diesem Fall nicht, es sei stattdessen die Strafprozessordnung relevant. Meine Anfrage könne man nicht beantworten, weil sie zum einen den Ermittlungserfolg gefährde und zum anderen der Aufwand nicht verhältnismäßig sei.

Ich fragte daraufhin nochmal beim niedersächsischen Datenschutzbeauftragten und bei der Bundesdatenschutzbeauftragten nach. Von ersterem erhielt ich eine kurze Antwort, die die juristische Ansicht der Staatsanwaltschaft leider bestätigte. Vom Büro der Bundesdatenschutzbeauftragten erhielt ich überhaupt keine Antwort. Weiter käme ich wohl nur mit Rechtsanwalt. Insofern war die Angelegenheit damit - unbefriedigend - beendet.

Am Ende bleibt für mich die unerfreuliche Erkenntnis, dass der Auskunftsanspruch im Bundesdatenschutzgesetz offenbar deutlich weniger wirksam ist als ich das erwartet hätte. Und eine sinnvolle Information, welche Accountdaten von mir gehackt wurden, habe ich weiterhin nicht.

tl;dr A very short key exchange crashes Chromium/Chrome. Other browsers accept parameters for a Diffie Hellman key exchange that are completely nonsense. In combination with recently found TLS problems this could be a security risk.

People who tried to access the webpage https://demo.cmrg.net/ recently with a current version of the Chrome browser or its free pendant Chromium have experienced that it causes a crash in the Browser. On Tuesday this was noted on the oss-security mailing list. The news spread quickly and gave this test page some attention. But the page was originally not set up to crash browsers. According to a thread on LWN.net it was set up in November 2013 to test extremely short parameters for a key exchange with Diffie Hellman. Diffie Hellman can be used in the TLS protocol to establish a connection with perfect forward secrecy.

For a key exchange with Diffie Hellman a server needs two parameters, those are transmitted to the client on a connection attempt: A large prime and a so-called generator. The size of the prime defines the security of the algorithm. Usually, primes with 1024 bit are used today, although this is not very secure. Mostly the Apache web server is responsible for this, because before the very latest version 2.4.7 it was not able to use longer primes for key exchanges.

The test page mentioned above tries a connection with 16 bit - extremely short - and it seems it has caught a serious bug in chromium. We had a look how other browsers handle short or nonsense key exchange parameters.

Mozilla Firefox rejects connections with very short primes like 256 bit or shorter, but connections with 512 and 768 bit were possible. This is completely insecure today. When the Chromium crash is prevented with a patch that is available it has the same behavior. Both browsers use the NSS library that blocks connections with very short primes.

The test with the Internet Explorer was a bit difficult because usually the Microsoft browser doesn't support Diffie Hellman key exchanges. It is only possible if the server certificate uses a DSA key with a length of 1024 bit. DSA keys for TLS connections are extremely rare, most certificate authorities only support RSA keys and certificates with 1024 bit usually aren't issued at all today. But we found that CAcert, a free certificate authority that is not included in mainstream browsers, still allows DSA certificates with 1024 bit. The Internet Explorer allowed only connections with primes of 512 bit or larger. Interestingly, Microsoft's browser also rejects connections with 2048 and 4096 bit. So it seems Microsoft doesn't accept too much security. But in practice this is mostly irrelevant, with common RSA certificates the Internet Explorer only allows key exchange with elliptic curves.

Opera is stricter than other browsers with short primes. Connections below 1024 bit produce a warning and the user is asked if he really wants to connect. Other browsers should probably also reject such short primes. There are no legitimate reasons for a key exchange with less than 1024 bit.

The behavior of Safari on MacOS and Konqueror on Linux was interesting. Both browsers accepted almost any kind of nonsense parameters. Very short primes like 17 were accepted. Even with 15 as a "prime" a connection was possible.

No browser checks if the transmitted prime is really a prime. A test connection with 1024 bit which used a prime parameter that was non-prime was possible with all browsers. The reason is probably that testing a prime is not trivial. To test large primes the Miller-Rabin test is used. It doesn't provide a strict mathematical proof for primality, only a very high probability, but in practice this is good enough. A Miller-Rabin test with 1024 bit is very fast, but with 4096 bit it can take seconds on slow CPUs. For a HTTPS connection an often unacceptable delay.

At first it seems that it is irrelevant if browsers accept insecure parameters for a key exchange. Usually this does not happen. The only way this could happen is a malicious server, but that would mean that the server itself is not trustworthy. The transmitted data is not secure anyway in this case because the server could send it to third parties completely unencrypted.

But in connection with client certificates insecure parameters can be a problem. Some days ago a research team found some possibilities for attacks against the TLS protocol. In these attacks a malicious server could pretend to another server that it has the certificate of a user connecting to the malicious server. The authors of this so-called Triple Handshake attack mention one variant that uses insecure Diffie Hellman parameters. Client certificates are rarely used, so in most scenarios this does not matter. The authors suggest that TLS could use standardized parameters for a Diffie Hellman key exchange. Then a server could check quickly if the parameters are known - and would be sure that they are real primes. Future research may show if insecure parameters matter in other scenarios.

The crash problems in Chromium show that in the past software wasn't very well tested with nonsense parameters in cryptographic protocols. Similar tests for other protocols could reveal further problems.

The mentioned tests for browsers are available at the URL https://dh.tlsfun.de/.

This text is mostly a translation of a German article I wrote for the online magazine Golem.de.

tl;dr Journalismus bangt um seine Finanzierung, aber Werbung nervt. Die Aufmerksamkeit für die Ereignisse um Adblock Plus ist völlig übertrieben. Die Idee der Acceptable Ads ist eigentlich vernünftig, die Medien sollten sie selbst aufgreifen.

In den letzten Tagen macht mal wieder eine Nachricht um den Werbeblocker Adblock Plus die Runde und wird von zahlreichen Medien aufgegriffen. Ich wollte mal meine Meinung dazu aufschreiben, das wird jetzt etwas länger. Vorneweg: Ich fühle mich in gewisser Weise zwischen den Stühlen. Ich verdiene mein Geld überwiegend mit Journalismus, ich kann aber sehr gut nachvollziehen, warum Menschen Adblocker einsetzen.

Die eine Seite: Zukunft des Journalismus

Der Journalismus ist in der Krise, das wissen wir spätestens seit dem Ende von dapd, der Financial Times Deutschland und dem Beinahe-Ende der Frankfurter Rundschau. Viele Menschen machen sich Sorgen um die Zukunft guter Berichterstattung und viele Journalisten machen sich Sorgen um ihren Job. Die Zukunft des Journalismus liegt im Internet, aber es gibt ein Problem: Bisher haben Zeitungen damit Geld verdient, bedrucktes Papier zu verkaufen und dieses Geschäftsmodell erodiert in rapider Geschwindigkeit. Im Internet Geld zu verdienen ist schwer. Es gibt im wesentlichen vier Möglichkeiten, mit Jouranlismus im Netz Geld zu verdienen: Werbung, bezahlte Inhalte, Spenden/Sponsoring und aus Steuern und Gebühren finanzierter Journalismus.

Keine dieser Möglichkeiten funktioniert sonderlich gut. Viele, die gute Inhalte produzieren, haben es verdammt schwer. Viele glauben, dass man die Nutzer nur irgendwann zum Bezahlen von Inhalten „umerziehen“ muss und dann alle ihre Paywalls anschalten, ich halte das aus verschiedenen Gründen für eine Illusion. Von allen Möglichkeiten, Onlinejournalismus zu finanzieren, funktioniert Werbung derzeit am besten. Nicht gut, aber für die meisten besser als alles andere.

Aber das Geschäftsmodell „Werbung“ wird angenagt. Immer mehr Nutzer nutzen Software wie Adblock Plus, ein relativ simpel zu installierendes Browserplugin.

Die andere Seite: Der genervte Nutzer

Wer heute ohne Werbeblocker im Netz surft bekommt den Eindruck die Werbeindustrie hat jedes Maß verloren. Werbung, die Musik abspielt, die wild blinkend um Aufmerksamkeit bettelt, die ihn ausspioniert, die das System auslastet oder die – das kommt immer wieder vor - versucht, Viren auf dem Rechner des Nutzers zu installieren oder ihn auf betrügerische Webangebote weiterleitet.

Die wenigsten installieren sich einen Adblocker leichtfertig. Denn auch das ist nervig und problembehaftet. Ich habe beispielsweise jahrelang ohne Werbeblocker gesurft. Schon lange vor es Adblock Plus überhaupt gab hatte ich mal ein Tool namens Privoxy installiert, es aber nach kurzer Zeit wieder deinstalliert. Jeder Werbeblocker bringt Probleme mit sich: Manche Seiten funktionieren nicht richtig, der Werbeblocker selbst will Speicher und Systemressourcen, kann für Browserabstürze verantwortlich sein und hat möglicherweise Sicherheitslücken. Werbeblocker installiert man sich erst dann, wenn die Nachteile durch Werbung so gravierend sind, dass sie die Nachteile eines Adblockers deutlich aufwiegen.

Diesen Punkt haben wir inzwischen erreicht und er führt dazu, dass gerade auf IT-Webseiten immer mehr Nutzer mit Adblockern unterwegs sind.

Die dritte Seite: Werbung an sich

Es gibt noch eine dritte Perspektive, die hier nicht verschwiegen werden soll und der ich einiges abgewinnen kann: Werbung ist eigentlich – aus gesellschaftlicher Sicht – eine reichlich dumme Angelegenheit. Werbung dient dazu, Menschen zu mehr Konsum zu bewegen. Sie fragt nicht, ob dieser Konsum irgendeinem Zweck dient. Sie bindet unglaubliche Mengen an Ressourcen und menschlicher Kreativität.

Diese Meinung mag nicht jeder im Detail teilen, aber mehr oder weniger denken vermutlich sehr viele Menschen so. Die wenigsten werden sagen: „Werbung ist etwas grundsätzlich tolles und schützenswertes.“ Schützenswert ist vielleicht der von der Werbung finanzierte Journalismus, aber nicht die Werbung selbst. Deswegen hat man auch wenig Hemmungen, Werbung zu blockieren. Man blockiert nichts wertvolles und hat nicht das Gefühl, etwas zu verpassen.

Es ist in gewisser Weise eine Tragik, dass so etwas sinnvolles wie Journalismus (bei aller Kritik im Detail) heute in starkem Maße von so etwas sinnlosem wie Werbung abhängt. Nein, einen einfachen Ausweg habe ich nicht anzubieten. Aber ich denke man muss sich dieses Dilemmas bewusst sein.

Der Streit zwischen mobilegeeks und Adblock Plus

Eine sehr erfolgreiche Software zum Blocken von Werbung ist das Browserplugin Adblock Plus. Adblock Plus hat vor einiger Zeit ein Programm für sogenannte „akzeptable Werbung“ (Acceptable Ads) eingeführt. Dafür hat Adblock Plus eine Reihe von Regeln, die wenig überraschen. Sie entspricht in vielen Punkten dem, was auch die meisten Nutzer als „akzeptable Werbung“ betrachten würden, etwa das Verbot von Sound in der Werbung oder von Layer Ads. Adblock Plus pflegt eine Whitelist von Seiten, die sie als akzeptabel betrachten und diese werden in der Standardeinstellung nicht blockiert.

Nun nimmt Adblock Plus von manchen Werbebetreibern auch Geld dafür, dass sie vom Werbeblocker ausgenommen werden. Das kann man fragwürdig finden. Der Betreiber der Webseite mobilegeeks Sascha Pallenberg berichtete darüber schon mehrfach, oft in ausgesprochen polemischer Weise („mafiöses Netzwerk“), und hat dabei eine erstaunliche Medienresonanz. Zuletzt berichtete mobilegeeks, dass Google und andere große Unternehmen an Adblock Plus nicht unerhebliche Beträge zahlen, um in die Liste der akzeptablen Werbung aufgenommen zu werden.

Dass eine Software mit Geschäftsmodellen arbeitet, die fragwürdig sind, kommt häufiger vor. Dass einiges von dem, was die Firma hinter Adblock Plus treibt, kritikwürdig ist, will ich nicht bezweifeln. Die gigantische Medienresonanz der Geschichte hat aber einen faden Beigeschmack. Die Süddeutsche, die Welt, die FAZ oder die Neue Züricher Zeitung sind üblicherweise keine Blätter, die besonders ausführlich über Netzthemen berichten oder sich für die Details seltsamer Geschäftsmodelle im Internet interessieren. Die ganze Geschichte wird viel größer gemacht als sie ist.

Der Effekt dürfte bei vielen Nutzern übrigens kaum sein, dass sie künftig ohne Adblocker surfen. Wer Adblock Plus misstraut, wird entweder das Acceptable Ads-Feature abschalten (ist problemlos möglich) oder auf einen alternativen Werbeblocker setzen, der ohne ein solches Feature auskommt (es gibt genügend davon).

Acceptable Ads

Grundsätzlich ist die Idee von Acceptable Ads nicht dumm. Die Medienbranche täte gut daran, die Diskussion darum, was an Werbung akzeptabel ist und was nicht, selbst zu führen. Man könnte sich etwa eine Selbstverpflichtung der Medienbranche ähnlich dem Pressekodex des deutschen Presserats vorstellen. Im Prinzip kommt man immer wieder zu ähnlichen Schlüssen, was akzeptable Werbung ist: Kein Blinken, kein Sound, keine Layer-Ads, kein Flash.

Nun gibt es allerdings ein Problem mit dem, was Adblock Plus unter Acceptable Ads versteht: Die Seite lässt manches durch, was zumindest ich alles andere als akzeptabel finde. So wurde etwa die Werbung eines Unternehmens namens YieldKit akzeptiert und dafür offenbar extra die Regeln, was akzeptable Werbung ist, geändert. YieldKit platziert via JavaScript Werbelinks in einen Text. Das greift schon die journalistisch gebotene Trennung von Werbung und Inhalt an. Wenn dafür Geld fließt, dass Adblock Plus derartiges durchlässt, dann ist die Kritik am Geschäftsmodell von Adblock Plus berechtigt. Aber die Grundidee, eine Diskussion über akzeptable Werbung anzustoßen, die halte ich nach wie vor für sinnvoll.

Man kann sich über manche Details sicher streiten. Ob Animationen generell verboten oder im bestimmten Rahmen erlaubt sein sollten etwa, oder ob Flash eine Existenzberechtigung hat. Manche Nutzer finden es spooky, wenn ihnen Werbebanner durchs Netz folgen, andere haben damit kein Problem. Aber es gibt denke ich zwei Punkte bei denen kann man sich nicht streiten: Sicherheit und Systemauslastung.

Adblocker als Schutz vor Malware

Werbung im Netz ist ein Sicherheitsrisiko. Werbeblocker sind eine sinnvolle Maßnahme, die Sicherheit beim Surfen zu erhöhen. Die Situation ist einigermaßen gruselig. Das BSI hat im letzten Jahr zweimal vor Malware in Werbebannern gewarnt. Es ging dabei nicht um die Schmuddelecken des Internets, zahlreiche populäre Webseiten waren betroffen.

Eine beliebte Software zur Verbreitung von Werbung nennt sich OpenX. OpenX hatte in der Vergangenheit immer wieder massive Sicherheitslücken. Im vergangenen Jahr verteilte die offizielle Webseite von OpenX eine gehackte Version mit einer Backdoor. Diese gehackte Version ist extrem verbreitet. Ich betreibe selber Webserver und habe schon mehrere Installationen davon stillgelegt. OpenX wird inzwischen nicht mehr weiterentwickelt, es gibt einen Nachfolger namens Revive, aber http://www.kreativrauschen.com/blog/2013/12/18/zero-day-vulnerability-in-openx-source-2-8-11-and-revive-adserver-3-0-1/ erst im Dezember wurde in Revive eine weitere massive Sicherheitslücke entdeckt.

Das ist nicht akzeptabel. Überhaupt nicht. Ein „wir bemühen uns, dass so etwas nicht vorkommt“ reicht nicht. Dafür kommt es viel zu oft vor. Ich möchte wissen, welche Strategie die Werbebranche hat, so etwas abzustellen. Ich möchte von den werbenden Webseiten, die mich darum bitten, meinen Adblocker abzuschalten, wissen, welche Software ihre Werbepartner einsetzen, denen sie immerhin die Sicherheit ihrer Kunden anvertrauen. Ich möchte wissen, warum noch niemand einen professionellen Audit von Revive organisiert hat oder Bug-Bounties bezahlt. Solange die Branche dieses Problem nicht soweit im Griff hat, dass das Risiko geringer ist als sich durch den Werbeblocker Sicherheitsprobleme einzuhandeln, werde ich weiterhin jedem, der mich um seine Meinung fragt (und das sind in Sachen PC-Sicherheit ein paar) sagen, dass Adblocker eine effektive Maßnahme zu mehr Sicherheit im Netz sind.

CPU-Last

Kommen wir zum Thema Systemlast. Werbung benötigt Rechenpower. Nicht ein bisschen, sondern ganz erheblich. Als es zuletzt mal wieder eine Kampagne von verschiedenen Medien mit der Nachricht „schaltet doch bitte Eure Adblocker aus“ gab, habe ich testweise die Seiten der beteiligten Medien mit Firefox und ohne Werbeblocker aufgerufen. Das Ergebnis war beeindruckend. Auf allen Seiten schnellte die Systemlast nach oben, in top (ein Tool unter Linux zum Anzeigen der Systemauslastung) waren abwechselnd Firefox und das Flash-Plugin ganz oben und benötigten über 50 Prozent der CPU-Leistung.

Ich habe dazu nur eine Frage: Wenn ihr schreibt „Bitte schaltet den Adblocker aus“ - meint ihr wirklich, dass sich eure Besucher deswegen einen schnelleren PC kaufen?

(Hinweis am Rande: Ich weiß, dass das Problem mit der CPU-Last unter Linux verstärkt auftritt, weil der Flash-Player für Linux so schlecht ist. Aber nein, das ist keine Entschuldigung.)

Ein Allmendeproblem

Nachdem ich gestern noch eine Weile über die Sache nachgedacht hab, ist mir ein offensichtliches Problem aufgefallen: Einzelne Nachrichtenwebseiten können vermutlich kaum etwas ausrichten. Werbeblocker deinstallieren werden die Nutzer nicht, wenn eine einzelne Webseite aufhört, nervige Werbung zu schalten. Die Nutzer darum zu bitten, ihren Werbeblocker auf einzelnen Webseiten auszuschalten, funktioniert vermutlich nur in sehr begrenztem Umfang.

Deswegen: Wenn einzelne, kleinere Webangebote voranpreschen und besonders nervige Werbeformen ausschließen, ist das löblich, es wird ihnen aber vermutlich wenig gedankt – ein klassisches Allmendeproblem. Das ganze müsste eine Debatte der Branche sein. Ein guter Anfang wäre es, wenn all diejenigen, die zuletzt entsprechende Appelle an ihre Besucher gestartet haben, sich auf eine Art Kodex einigen würden. Da wäre schon ein relevanter Anteil der deutschsprachigen Nachrichtenwelt zusammen.

Datenschutz

Was ich bis jetzt nur am Rande gestreift habe: Das Thema Datenschutz. Nicht weil ich es vergessen habe, sondern weil ich das Gefühl hatte es verkompliziert die ganze Debatte noch enorm. Werbung wird heute fast immer nicht über die jeweilige Seite selbst sondern über externe Vermarkter ausgeliefert. Das bedeutet automatisch: Der Werbevermarkter bekommt nicht nur Aufmerksamkeit, sondern auch Daten. Dazu kommen noch zahlreiche Services, die ausschließlich Daten abgreifen und für den Nutzer komplett unsichtbar sind. Nicht wenige davon sind gerade für journalistische Angebote kaum verzichtbar, etwa die Zählpixel der VG Wort oder die Statistiken der IVW. Das darf aber nicht darüber hinwegtäuschen: Gerade diese Services dürften inzwischen ein enormes Datenmaterial mit großen Missbrauchspotential haben.

Fazit

Werbung ist doof, aber sie wird auf absehbare Zeit ein wichtiges finanzielles Standbein des Journalismus bleiben. Wenn ihr wollt, dass die Leute aufhören, Adblocker einzusetzen: Macht Werbung erträglich. Dann wird die Rate derer, die sich Werbeblocker installieren, ganz von selbst zurückgehen. Ja, das bedeutet Konflikte mit den Werbevermarktern. Ja, ihr müsst denen erklären, dass Flash doof ist und dass ihr es Euren Nutzern nicht zumuten könnt, wegen ihrer Banner neue Rechner zu kaufen. Nein, von dem Werbebetreiber, der letzten Monat einen Virus verbreitet hat, solltet ihr keine Werbebanner schalten. Ja, es kann dazu führen, dass ihr kurzfristig finanziell lukrative Werbung nicht mehr schalten könnt.

Disclaimer / conflict of interest: Ich benutze auf diesem Blog Google Ads. Google scheint die einzige Firma zu sein, die richtig viel Geld mit Werbung verdient und trotzdem in der Regel das tut, was die meisten als akzeptable Werbung ansehen (mit der großen Ausnahme Datenschutz). Außerdem benutze ich Zählpixel der VG Wort und einen flattr-Button. Ich schreibe regelmäßig Texte für die IT-Nachrichtenseite Golem.de, die an einer der jüngsten Kampagnen zum Thema Adblocker beteiligt war.

Bildquellen: Leuchtreklame von Wikimedia Commons (Public Domain), restliche Bilder Screenshots.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) macht ja seit vorgestern mächtig Wirbel um einige Zugangsdaten, die sie angeblich aus einem Botnetz haben. Leider informiert das BSI bislang nur sehr spärlich über Details. Ich habe, nachdem die zugehörige Webseite nach einigen Stunden wieder einigermaßen erreichbar war, verschiedene von mir in der Vergangenheit genutzte Mailadressen prüfen lassen. Bei einer Mailadresse eines großen deutschen Freemail-Anbieters, die ich vor langer Zeit als primäre Mailadresse genutzt hatte, schlug der Test an und ich bekam eine der Warnmails (ich dokumentiere die Mail weiter unten). Das ist jetzt aus zwei Gründen interessant:

1. Ich habe diese Mailadresse seit ungefähr zehn Jahren nicht genutzt. Ich habe alle Accounts, die ich aktiv nutze, auf meine aktuelle Mailadresse auf eigener Domain umgestellt. Das bedeutet: Die Daten, die das BSI da hat, sind also - zumindest teilweise - uralt.

Eine Sache, die hier vielleicht spannend ist: Im November letztes Jahr gab es einen größeren Leak von Accountdaten bei Adobe. Da war ein Account mit dieser Mailadresse dabei (fragt mich nicht warum ich irgendwann einen Adobe-Account hatte, wie gesagt, ist mindestens zehn Jahre her). Es ist natürlich reine Spekulation, aber es scheint mir zumindest vorstellbar, dass es sich bei den BSI-Daten schlicht um die selben Daten handelt. Rein zeitlich würde es ins Bild passen. (Update: Mehrere Leute teilten mir mit dass sie vom Adobe-Leak betroffene Mailadressen haben, die das BSI nicht kennt, also Spekulation höchstwahrscheinlich falsch)

2. Ich erhalte hier eigentlich eine völlig nutzlose Warnung und unpraktikable Tipps. Denn was mir das BSI letztendlich mitteilt: Sie haben Zugangsdaten zu irgendeinem Account irgendwo im Zusammenhang mit einer Mailadresse von mir. Oder, um das BSI zu zitieren: "Dieses Konto verwenden Sie möglicherweise bei einem Sozialen Netzwerk, einem Online-Shop, einem E-Mail-Dienst, beim Online-Banking oder einem anderen Internet-Dienst."

Verbunden ist das ganze mit dem kaum umsetzbaren Vorschlag, ich solle doch am besten alle meine Passwörter ändern.

Was ich ja jetzt gern wüsste: Weiß das BSI, um was für einen Account es geht? Und falls ja: Warum teilen sie es mir nicht mit? Ich werde zumindest versuchen, darauf eine Antwort zu erhalten. Laut Bundesdatenschutzgesetz ist das BSI verpflichtet, mir Auskünfte über Daten, die sie über mich gespeichert haben, zu erteilen.

Hier die vollständige Mail, die man vom BSI erhält:

Sehr geehrte Dame, sehr geehrter Herr,

Sie haben diese E-Mail erhalten, weil die E-Mail-Adresse [...] auf der Webseite www.sicherheitstest.bsi.de eingegeben und überprüft wurde.

Die von Ihnen angegebene E-Mail-Adresse [...] wurde zusammen mit dem Kennwort eines mit dieser E-Mail-Adresse verknüpften Online-Kontos von kriminellen Botnetzbetreibern gespeichert. Dieses Konto verwenden Sie möglicherweise bei einem Sozialen Netzwerk, einem Online-Shop, einem E-Mail-Dienst, beim Online-Banking oder einem anderen Internet-Dienst.

Um diesen Missbrauch zukünftig zu verhindern, empfiehlt das BSI die folgenden Schritte:

1. Überprüfen Sie Ihren eigenen Rechner sowie weitere Rechner, mit denen Sie ins Internet gehen, mittels eines gängigen Virenschutzprogramms auf Befall mit Schadsoftware.

2. Ändern Sie alle Passwörter, die Sie zur Anmeldung bei Online-Diensten nutzen.

3. Lesen Sie die weiteren Informationen hierzu unter www.sicherheitstest.bsi.de.

Diese E-Mail ist vom BSI signiert. Wie Sie die Signatur überprüfen können erfahren Sie auch unter www.sicherheitstest.bsi.de.

Mit freundlichen Grüßen
Ihr BSI-Sicherheitstest-Team

Based on the XKCD comic "Up Goer Five", someone made a nice little tool: An online text editor that lets you only use the 1000 most common words in English. And ask you to explain a hard idea with it.

Nice idea. I gave it a try. The most obvious example to use was my diploma thesis (on RSA-PSS and provable security), where I always had a hard time to explain to anyone what it was all about.

Well, obviously math, proof, algorithm, encryption etc. all are forbidden, but I had a hard time with the fact that even words like "message" (or anything equivalent) don't seem to be in the top 1000.

Here we go:

When you talk to a friend, she or he knows you are the person in question. But when you do this a friend far away through computers, you can not be sure.
That's why computers have ways to let you know if the person you are talking to is really the right person.

The ways we use today have one problem: We are not sure that they work. It may be that a bad person knows a way to be able to tell you that he is in fact your friend. We do not think that there are such ways for bad persons, but we are not completely sure.

This is why some people try to find ways that are better. Where we can be sure that no bad person is able to tell you that he is your friend. With the known ways today this is not completely possible. But it is possible in parts.

I have looked at those better ways. And I have worked on bringing these better ways to your computer.

So - do you now have an idea what I was taking about?

I found this nice tool through Ben Goldacre, who tried to explain randomized trials, blinding, systematic review and publication bias - go there and read it. Knowing what publication bias and systematic reviews are is much more important for you than knowing what RSA-PSS is. You can leave cryptography to the experts, but you should care about your health. And for the record, I recently tried myself to explain publication bias (german only).

Two days ago, the german Chaos Computer Club (CCC) published a sample that's supposedly a variant of a german state spy software (the so-called "Bundestrojaner").

You might wonder if your anti virus software is protecting you. The webpage Virus Total lets you upload suspicious files, scans them with 43 different anti virus applications and presents you the result. Currently, 24 of 43 scanners detect the Bundestrojaner.

The CCC provides some further information where they state that the file they released is not the original one - they had several samples that differed and to avoid detection of the potential source, they changed the differing parts to something completely else. You might wonder if your anti virus app also detects the "original" Bundestrojaner and not just the modified file the CCC released.

We can easily check this if we change the modified pieces again to something else. A modified variant lowered the detection rate to 14 of 43 - amongst them the popular McAffee software. Now, it's pretty useless to only detect the exact published sample of a malware if we know that the original malware is different.

Application	Version	Sig date	Modified sample	Original CCC sample
AhnLab-V3	2011.10.08.01	2011-Okt-09	Trojan/Win32.R2d2	Trojan/Win32.R2d2
AntiVir	7.11.15.175	2011-Okt-09	TR/GruenFink.1	TR/GruenFink.1
Antiy-AVL	2.0.3.7	2011-Okt-09	-	-
Avast	6.0.1289.0	2011-Okt-09	Win32:Trojan-gen	Win32:Trojan-gen
AVG	10.0.0.1190	2011-Okt-07	-	-
BitDefender	7.2	2011-Okt-10	Backdoor.R2D2.A	Backdoor.R2D2.A
ByteHero	1.0.0.1	2011-Sep-23	-	-
CAT-QuickHeal	11.00	2011-Okt-07	-	-
ClamAV	0.97.0.0	2011-Okt-10	Trojan.BTroj-1	Trojan.BTroj-1
Commtouch	5.3.2.6	2011-Okt-10	-	W32/R2D2.A
Comodo	10407	2011-Okt-10	-	Backdoor.Win32.R2D2.A
DrWeb	5.0.2.03300	2011-Okt-10	-	-
Emsisoft	5.1.0.11	2011-Okt-10	Trojan.Win32.Bundestrojaner!A2	Backdoor.Win32.R2D2!IK
eSafe	7.0.17.0	2011-Okt-06	-	-
eTrust-Vet	36.1.8605	2011-Okt-07	-	-
F-Prot	4.6.2.117	2011-Okt-09	-	W32/R2D2.A
F-Secure	9.0.16440.0	2011-Okt-10	Backdoor:W32/R2D2.A	Backdoor:W32/R2D2.A
Fortinet	4.3.370.0	2011-Okt-10	-	W32/R2D2.A!tr.bdr
GData	22	2011-Okt-10	Backdoor.R2D2.A	Backdoor.R2D2.A
Ikarus	T3.1.1.107.0	2011-Okt-10	-	Backdoor.Win32.R2D2
Jiangmin	13.0.900	2011-Okt-09	-	-
K7AntiVirus	91155258	2011-Okt-08	-	-
Kaspersky	9.0.0.837	2011-Okt-09	Backdoor.Win32.R2D2.a	Backdoor.Win32.R2D2.a
McAfee	5.400.0.1158	2011-Okt-10	-	Artemis!930712416770
McAfee-GW-Edition	2010.1D	2011-Okt-09	-	Artemis!930712416770
Microsoft	17702	2011-Okt-10	Backdoor:Win32/R2d2.A	Backdoor:Win32/R2d2.A
NOD32	6529	2011-Okt-10	Win32/R2D2.A	Win32/R2D2.A
Norman	6.7.2011	2011-Okt-09	-	-
nProtect	2011-10-10.01	2011-Okt-10	-	-
Panda	10.0.3.5	2011-Okt-09	-	Suspiciousfile
PCTools	8.0.0.5	2011-Okt-10	Backdoor.R2D2	Backdoor.R2D2
Prevx	3.0	2011-Okt-10	-	-
Rising	23.78.06.02	2011-Okt-09	-	-
Sophos	4.70.0	2011-Okt-10	Troj/BckR2D2-A	Troj/BckR2D2-A
SUPERAntiSpyware	4.40.0.1006	2011-Okt-08	-	-
Symantec	20111.2.0.82	2011-Okt-10	Backdoor.R2D2	Backdoor.R2D2
TheHacker	6.7.0.1.318	2011-Okt-09	-	-
TrendMicro	9.500.0.1008	2011-Okt-09	-	-
TrendMicro-HouseCall	9.500.0.1008	2011-Okt-10	-	BKDR_R2D2.A
VBA32	3.12.16.4	2011-Okt-07	-	-
VIPRE	10718	2011-Okt-10	-	Trojan.Win32.Generic!BT
ViRobot	2011.10.10.4710	2011-Okt-10	-	-
VirusBuster	14.1.3.0	2011-Okt-09	-	-

Scans done Monday morning around 8:00.

OpenLeaks is a planned platform like WikiLeaks, founded by ex-Wikileaks member Daniel Domscheit-Berg. It's been announced a while back and a beta is currently presented in cooperation with the newspaper taz during the Chaos Communication Camp (where I am right now).

I had a short look and found some things noteworthy:
The page is SSL-only, any connection attempt with http will be forwarded to https. When I opened the page in firefox, I got a message that the certificate is not valid. That's obviously bad, although most people probably won't see this message.

What is wrong here is that an intermediate certificate is missing - we have a so-called transvalid certificate (the term "transvalid" has been used for it by the EFF SSL Observatory project). Firefox includes the root certificate from Go Daddy, but the certificate is signed by another certificate which itself is signed by the root certificate. To make this work, one has to ship the so-called intermediate certificate when opening an SSL connection.

The reason why most people won't see this warning and why it probably went unnoticed is that browsers remember intermediate certificates. If someone ever was on a webpage which uses the Go Daddy intermediate certificate, he won't see this warning. I saw it because I usually don't use Firefox and it had a rather fresh configuration.

There was another thing that bothered me: On top of the page, there's a line "Before submitting anything verify that the fingerprints of the SSL certificate match!" followed by a SHA-1 certificate fingerprint. Beside the fact that it's english on a german page, this is a rather ridiculous suggestion. Checking a fingerprint of an SSL connection against one you got through exactly that SSL connection is bogus. Checking a certificate fingerprint doesn't make any sense if you got it through a connection that was secured with that certificate. If checking a fingerprint should make sense, it has to come through a different channel. Beside that, nowhere is explained how a user should do that and what a fingerprint is at all. I doubt that this is of any help for the targetted audience by a whistleblower platform - it will probably only confuse people.

Both issues give me the impression that the people who designed OpenLeaks don't really know how SSL works - and that's not a good sign.

I've written in the past about the EFF SSL Observatory. It's a great project that has scanned the whole IP space for SSL-certificates used in HTTPS. They provide a database with meta information and their project found a couple of issues where CAs have issued certificates with weak security settings and violation of their own policies. CAcert is a project which tries to be the "better SSL authority" - it issues certificates for free, based on a web-of-trust community. The CAcert root certificate is not part of any major web browser. The EFF has mainly analyzed the browser-accepted CAs - but they provide the data, so I could do it myself.

I did some checks on the all_certs table selecting the certificates from cacert. I found out that there were 143 valid certificates with 512 bit. That is completely insecure and breakable by a home computer today. I also found that the majority of certificates still has 1024 bit, which by today's standards should be considered harmful - there have been no public breaks yet, but it's expected that it's possible to build an RSA-1024 cracker for an attacker with enough money.

I did the following query on the database:
SELECT RSA_Modulus_Bits, count(*) FROM all_certs WHERE `Validity:Not After datetime` > '2010-03-08' AND ( `Issuer` like '%CAcert.org%' OR `Issuer` like '%cacert.org') GROUP BY `RSA_Modulus_Bits` ORDER BY count(*);

+------------------+----------+
| RSA_Modulus_Bits | count(*) |
+------------------+----------+
[...]
| 512              |      143 |
| 4096             |      632 |
| 2048             |     3716 |
| 1024             |     5790 |
+------------------+----------+

Now, what further checks can we do? I checked for the RSA exponent. I found two certificates in the database with exponent 3. RSA with low exponent is also considered insecure, although one has to state that this is not a serious issue. RSA with low exponents is not insecure by itself, but it can create vulnerabilities in combination with other issues (if you're interested in details, read my diploma thesis).

I have not checked the CAcert database for the Debian SSL vulnerability, as that would've been non-trivial. There were scripts shipped with the SSL Observatory data, but I found them not easy to use, so I skipped that part.

My suggestions to cacert were to revoke all certificates with serious issues (like the 512 bit certificates). Also, I suggested that new certificates with insecure settings like RSA below 2048 bits or a low exponent should not be allowed. CAcert did most of this. By now, all 512 bit certificates should be revoked and it is impossible to create new ones below 1024 bit or with low exponents. It is however still possible to create 1024 bit certificates, which is due to a limitation in the client certificate creation script for the Internet Explorer. They say they're working on this and plan to prevent 1024 bit certificates in the future. They also told me that they've checked for the Debian SSL bug.

I've reported the issue on the 11th March and got a reply on the same day - that's pretty okay, one slight thing still: There was no security contact with a PGP key listed on the webpage (but I got a PGP-encrypted contact once I asked for it). That's not good, I expect especially from a security project that I can contact them for security issues with encrypted mail. One can also argue if four months is a bit long to fix such an issue, but as it was far away from being trivial, this can be apologized.

I'd say that I'm quite satisfied with the reactions of CAcert. I always got fast replies to questions I had and the issues were resolved in a proper way. I have other points of criticism on the security of CAcert, the issue that bothers me most is that they still use SHA-1 and refuse to switch to a more secure hashing algorithm like SHA-512, although all major browsers have support for this since a long time.

I want to encourage others to do further tests on CAcert. I'd like to see CAcert being an authority that does better than the commercial ones. The database from the observatory is a treasure and should be used by projects like CAcert to improve their security.

The Electronic Frontier Foundation is running a fascinating project called the SSL Observatory. What they basically do is quite simple: They collected all SSL certificates they could get via https (by scanning all possible IPs), put them in a database and made statistics with them.

For an introduction, watch their talk at the 27C3 - it's worth it. For example, they found a couple of "Extended Validation"-Certificates that clearly violated the rules for extended validation, including one 512-bit EV-certificate.

The great thing is: They provide the full mysql database for download. I took the time to import the thing locally and am now able to run my own queries against it.

Let's show some examples: I'm interested in crypto algorithms used in the wild, so I wanted to know which are used in the wild at all. My query:

SELECT `Signature Algorithm`, count(*) FROM valid_certs GROUP BY `Signature Algorithm` ORDER BY count(*);

shows all signature algorithms used on the certificates.
And the result:

+--------------------------+----------+
| Signature Algorithm      | count(*) |
+--------------------------+----------+
|  sha512WithRSAEncryption |        1 |
|  sha1WithRSA             |        1 |
|  md2WithRSAEncryption    |        4 |
|  sha256WithRSAEncryption |       62 |
|  md5WithRSAEncryption    |    29958 |
|  sha1WithRSAEncryption   |  1503333 |
+--------------------------+----------+

Nothing very surprising here. Seems nobody is using anything else than RSA. The most popular hash algorithm is SHA-1, followed by MD5. The transition to SHA-256 seems to go very slowly (btw., the most common argument I heared when asking CAs for SHA-256 certificates was that Windows XP before service pack 3 doesn't support that). The four MD2-certificates seem interesting, though even that old, it's still more secure than MD5 and provides a similar security margin as SHA-1, though support for it has been removed from a couple of security libraries some time ago.

This query was only for the valid certs, meaning they were signed by any browser-supported certificate authority. Now I run the same query on the all_certs table, which contains every cert, including expired, self-signed or otherwise invalid ones:

+-------------------------------------------------------+----------+
| Signature Algorithm                                   | count(*) |
+-------------------------------------------------------+----------+
|  1.2.840.113549.27.1.5                                |        1 |
|  sha1                                                 |        1 |
|  dsaEncryption                                        |        1 |
|  1.3.6.1.4.1.5849.1.3.2                               |        1 |
|  md5WithRSAEncryption ANDALSO  md5WithRSAEncryption   |        1 |
|  ecdsa-with-Specified                                 |        1 |
|  dsaWithSHA1-old                                      |        2 |
|  itu-t ANDALSO  itu-t                                 |        2 |
|  dsaWithSHA                                           |        3 |
|  1.2.840.113549.1.1.10                                |        4 |
|  ecdsa-with-SHA384                                    |        5 |
|  ecdsa-with-SHA512                                    |        5 |
|  ripemd160WithRSA                                     |        9 |
|  md4WithRSAEncryption                                 |       15 |
|  sha384WithRSAEncryption                              |       24 |
|  GOST R 34.11-94 with GOST R 34.10-94                 |       25 |
|  shaWithRSAEncryption                                 |       50 |
|  sha1WithRSAEncryption ANDALSO  sha1WithRSAEncryption |       72 |
|  rsaEncryption                                        |       86 |
|  md2WithRSAEncryption                                 |      120 |
|  GOST R 34.11-94 with GOST R 34.10-2001               |      378 |
|  sha512WithRSAEncryption                              |      513 |
|  sha256WithRSAEncryption                              |     2542 |
|  dsaWithSHA1                                          |     2703 |
|  sha1WithRSA                                          |    60969 |
|  md5WithRSAEncryption                                 |  1354658 |
|  sha1WithRSAEncryption                                |  4196367 |
+-------------------------------------------------------+----------+

It seems quite some people are experimenting with DSA signatures. Interesting are the number of GOST-certificates. GOST was a set of cryptography standards by the former soviet union. Seems the number of people trying to use elliptic curves is really low (compared to the popularity they have and that if anyone cares for SSL performance, they may be a good catch). For the algorithms only showing numbers, 1.2.840.113549.1.1.10 is RSASSA-PSS (not detected by current openssl release versions), 1.3.6.1.4.1.5849.1.3.2 is also a GOST-variant (GOST3411withECGOST3410) and 1.2.840.113549.27.1.5 is unknown to google, so it must be something very special.

Having used my PGP key 3DBD3B20 for almost eight years, it's finally time for a new one: 4F9F43A9. The old primary key was a 1024 bit DSA key, which had two drawbacks:
1. 1024 bit keys for DLP or factoring based algorithms are considered insecure.
2. It's impossible to set the used hash algorithm to anything beyond SHA-1.

My new key has 4096 bits key size (2048 bit is the default of GnuPG since 2.0.13 and should be fairly enough, but I wanted some extra security) and the default hash algorithm preference is SHA-256. I had to make a couple of decisions for my name in the key:
1. I'm usually called Hanno, but my real/official name is Johannes.
2. My surname has a special character (ö) in it, which can be represented as oe.

In my previous keys, I've mixed this. I decided against this for the new key, because both my inofficial prename Hanno and my umlaut-converted surname Boeck are part of my mail adress, so people should still be able to find my key if they're searching for that.

Another decision was the time I wanted my key to be valid. I've decided to give it an expiration date, but a fairly long one: 10 years from now.

I've signed my new key with my old key, so if you've signed my old one, you should be able to verify the new one. I leave it up to you if you decide to sign my new key or if you want to re-new the signing procedure. I'll start from scratch and won't sign any keys I've signed with the old key automatically with the new one. If you want to key-sign with me, you may find me on the 27C3 within the next days.

My old key will be valid for a while, at some time in the future I'll probably revoke it.

Update: I just found out that having a key without SHA-1 is trickier than I thought. The self-signatures were still SHA-1. I could re-do the self-signatures and revoke the old ones, but that'd clutter the key with a lot of useless cruft and as the new key wasn't around long and didn't get any signatures I couldn't get easily again, I decided to start over again: The new key is BBB51E42 and the other one will be revoked.
I'll write another blog entry to document how you can create your own SHA-256 only key.

Prologue of this story: A very long time ago (2004 to be exact), I decided to create a new PGP / GnuPG key with 4096 bits (due to this talk). However, shortly after that, I had a hardware failure of my hard disc. The home was a dm-crypt partition with xfs. I was able to restore most data, but it seemed the key was lost. I continued to use my old key I had in a backup and the 4096 key was bitrotting on keyservers. And that always annoyed me. In the meantime, I found all private keys of old DOS (2.6.3i) and Windows (5.0) PGP keys I had created in the past and revoked them, but this 4096 key was still there.

I still have the hard disc in question and a couple of dumps I created during the data rescue back then. Today, I decided that I'll have to try restoring that key again. My strategy was not trying to do anything on the filesystem, but only operate within the image. Very likely the data must be there somewhere.



I found a place where I was rather sure that this must be the key. But exporting that piece with dd didn't succeed - looking a bit more at it, it seemed that the beginning was in shape, but at some place there were zeros. I don't know if this is due to the corruption or the fact that the filesystem didn't store the data sequentially at that place - but it didn't matter. I had a look at the file format of PGP keys in RFC 4880. Public keys and private keys are stored pretty similar. Only the beginning (the real "key") part differs, the userid / signatures / rest part is equal. So I was able to extract the private key block (starting with 0x95) with the rest (I just used the place where the first cleartext userid started with my name "Johannes"). What should I say? It worked like a charm. I was able to import my old private key and was able to revoke it. Key 147C5A9F is no longer valid. Great!

P. S.: Next step will be finally creating a new 4096 bit RSA key and abandoning my still-in-use 1024 bit DSA key for good.

Yesterday I was at a talk at the FSFE Berlin about free software and GSM. It was an interesting talk and discussion.
Probably most of you know that GSM is the protocol that keeps the large majority of mobile phones running. In the past, only a handful of companies worked with the protocol and according to the talk, even most mobile phone companies don't know much of the internal details, as they usually buy ready-made chips.
Three free software projects work on GSM, OpenBTS and OpenBSC on the server side and OsmocomBB on the client side. What I didn't know yet and think is really remarkable: The Island State of Niue installed a GSM-network based on OpenBTS. The island found no commercial operator, so they installed a free software based and community supported GSM network.

Afterwards, we had a longer discussion about security and privacy implications of GSM. To sum it up, GSM is horribly broken on the security side. It offers no authentication between phones and cells. Also, it's encryption has been broken in the early 90s. There is not much progress in protocol improvements although this is known for a very long time. It's also well known that so-called IMSI-cachers are sold illegally for a few thousand dollars. The only reason GSM is still working at all is basically that those possibilities still cost a few thousands. But cheaper hardware and improvement in free GSM software makes it more likely that those possibilities will have a greater impact in the future (this is only a brief summary and I'm not really in that topic, see Wikipedia for some starting points for more info).

There was a bit of discussion about the question how realistic it is that some "normal user" is threatened by this due to the price of a few thousand dollars for the equipment. I didn't bring this up in the discussion any more, but I remember having seen a talk by a guy from Intel that the tendency is to design generic chips for various protocols that can be GSM, Bluetooth or WLAN purely by software control. Thinking about that, this raises the question of protocol security even more, as it might already be possible to use mainstream computer hardware to do mobile phone wiretapping by just replacing the firmware of a wireless lan card. It almost certainly will be possible within some years.

Another topic that was raised was frequency regulation. Even with free software you wouldn't be able to operate your own GSM network, because you couldn't afford buying a frequency (although it seems to be possible to get a testing license for a limited space, e. g. for technical workshops - the 27C3 will have a GSM test network). I mentioned that there's a chapter in the book "Code" from Lawrence Lessig (available in an updated version here, chapter is "The Regulators of Speech: Distribution" and starts on page 270 in the PDF). The thoughts from Lessing are that frequency regulation was neccessary in the beginning of radio technology, but today, it would be easily possible to design protocols that don't need regulation - they could be auto-regulating, e. g. with a prefix in front of every data package (the way wireless lan works). But the problem with that is that today, frequency usage generates large income for the state - that's completely against the original idea of it, as it's primarily purpose was to keep technology usable.

In 2008, a rather interesting new kind of security problem within web applications was found called Clickjacking. The idea is rather simple but genious: A webpage from the attacked web application is loaded into an iframe (a way to display a webpage within another webpage), but so small that the user cannot see it. Via javascript, this iframe is always placed below the mouse cursor and a button is focused in the iframe. When the user clicks anywhere on an attackers page, it clicks the button in his webapp causing some action the user didn't want to do.
What makes this vulnerability especially interesting is that it is a vulnerability within protocols and that it was pretty that there would be no easy fix without any changes to existing technology. A possible attempt to circumvent this would be a javascript frame killer code within every web application, but that's far away from being a nice solution (as it makes it neccessary to have javascript code around even if your webapp does not use any javascript at all).
Now, Microsoft suggested a new http header X-FRAME-OPTIONS that can be set to DENY or SAMEORIGIN. DENY means that the webpage sending that header may not be displayed in a frame or iframe at all. SAMEORIGIN means that it may only be referenced from webpages on the same domain name (sidenote: I tend to not like Microsoft and their behaviour on standards and security very much, but in this case there's no reason for that. Although it's not a standard – yet? - this proposal is completely sane and makes sense).
Just recently, Firefox added support, all major other browser already did that before (Opera, Chrome), so we finally have a solution to protect against clickjacking (konqueror does not support it yet and I found no plans for it, which may be a sign for the sad state of konqueror development regarding security features - they're also the only browser not supporting SNI). It's now up to web application developers to use that header. For most of them – if they're not using frames at all - it's probably quite easy, as they can just set the header to DENY all the time. If an app uses frames, it requires a bit more thoughts where to set DENY and where to use SAMEORIGIN.
It would also be nice to have some "official" IETF or W3C standard for it, but as all major browsers agree on that, it's okay to start using it now.
But the main reason I wrote this long introduction: I've set up a little test page where you can check if your browser supports the new header. If it doesn't, you should look for an update.