Bernds Blog

Heute bzw. gestern Abend kamen mal wieder ein paar Artikel zum geplanten E-Mail-Dienst des Innenministeriums namens »DE-Mail« in der Onlinepresse.

Kurz gefasst denke ich, dass dieses Projekt das Potenzial hat, sich in eine Reihe unrühmlicher Geldgräber einzugliedern.

Besonders gefallen hat mir der Heise-Artikel dazu. Ich möchte mal etwas pedantisch auf ein paar Abschnitten herumreiten:

Schallbruch teilte auch die Kritik aus dem Bereich der kommunalen Anwender des OSCI-Standards (Online Services Computer Interface) nicht, wonach auf dieser Basis bereits Möglichkeiten zum verschlüsselten E-Mail- und Dokumentenversand über gängige Mail-Adressen bestünden. Dafür bräuchte es bei allen Kommunikationspartnern komplizierte Verschlüsselungsarchitekturen. Beide Seiten müssten auf ihrem eigenen PC einen OSCI-Client installieren, wobei keiner für die Systemsicherheit bürgen könne.

Der neue Dient wird also »sicher«. Absolut sicher. Schließlich verbürgt sich da jemand dafür. Ich frage mich nur: Wer? Wenn ich den Dienst nutze und ein Sicherheits-Problem auftritt. Wer zahlt mir dann eine Entschädigung? Der Bund? Die beteiligten Firmen? Der Vorstandsvorsitzende der verantwortlichen Firma? Oder ist diese Art des Verbürgens vielleicht eher sowas wie: »Wenn es ein Problem gibt, werden wir aber ganz energisch mit dem Zeigefinger fuchteln bis jemand sagt, dass wir das in Zukunft besser machen«?

Zugleich verwies der IT-Direktor auf hohe Kostensenkungseffekte. Wenn allein acht Prozent des derzeitigen Postverkehrs über das neue Verfahren abgewickelt würden, könnten die Absender eine Milliarde Euro Porto sparen. Dieser Summe stünden Aufwendungen für den Aufbau der Kommunikationsinfrastrukturen gegenüber.

Okay, auch wenn wir mal annehmen, dass mit dieser vorsichtigen Formulierung nicht ausgeschlossen werden soll, dass die Milliarde sofort wieder in die Kommunikationsinfrastruktur gepumpt wird, dann verliert die Post also eine Milliarde (in einem nicht genannten Zeitraum, möglicherweise pro Jahr). Diese Milliarde wird dann also als Finanzhilfe wieder investiert weil es dem Konzern dann plötzlich schlecht geht wenn keiner mehr Briefe verschickt. Ergo: Milchmädchenrechnung.

Aber das sind ja Details. Richtig schlecht wird mir dann bei sowas:

Die ganzen Sicherheitsmechanismen sollten beim Provider im Hintergrund ablaufen, um die Nutzung so einfach wie möglich zu machen. So sei dort etwa eine Kontrolle auf Schadsoftware und eine Versandberechtigung, die Integritätssicherung über eine Prüfsumme, die Verschlüsselung über S/MIME und eine Ergänzung von Metadaten durchzuführen.

Bitte nochmal langsam lesen.
Ja, die begründen ihre Sicherheit wirklich damit, dass beim Provider die Daten verschlüsselt werden. Damit der seine Daten dort eintragen kann wird dann vermutlich eine normale end-to-end-Verschlüsellung nicht vorgesehen werden oder wie? Zudem: Schadsoftware? Hieß es nicht eben noch, der Dienst sei spamfrei? Ist er vielleicht nur ein bisschen spamfrei?

Ich habe dazu folgende Quellen in den letzten Tagen zufällig gefunden...
Auf Heise.de einen Artikel, in dem die Speicherdauer bei YouTube thematisiert wird:

YouTube lösche üblicherweise nach sieben Tagen die IP-Adressen der Rechner, von denen Dateien in das Internetportal eingestellt werden.

Dazu ein weiterer Heise-Artikel, der die IP-Adressen-Speicherung bei der Suchmaschine von Google behandelt:

Der Suchmaschinenbetreiber Google will die Haltedauer für die IP-Adresse bei Suchanfragen bis Ende September von bisher 18 auf künftig neun Monate reduzieren, danach werden die Anfragen anonymisiert.

Besonders nett ist natürlich die Begründung dieser neun Monate Speicherung in eben letzterem Artikel:

Laut dem Datenschutzbeauftragten des Konzerns, Peter Fleischer, sucht Google die Balance zwischen dem Datenschutz auf der einen Seite und den Interessen von Google auf der anderen. Letztere bestehen darin, die eigenen Dienste kontinuierlich zu verbessern und gegen Missbrauch und Angriffe zu schützen [...] (Hervorhebung von mir)

Missbrauch und Angriffe sind bei jedem Server und jedem öffentlich zugänglichen Angebot natürlich immer eine Möglichkeit. Daher habe ich an der einwöchigen Speicherung von IP-Adressen bei YouTube noch nichtmal grundlegend etwas auszusetzen. Ich finde es nicht gut, aber es tanzt nicht aus der Reihe anderer ("normaler") Websites.

Anders dagegen die Speicherung bei der Suchmaschine. Eine Internet-Suche hat ein für mich schwer erkennbares Missbrauchspotenzial. Auf YouTube kann man eigene Mediendaten hochladen, dabei sowohl bzgl. Urheberrecht als auch bzgl. Beleidigungen und ähnlichem unschöne Dinge tun. Durch eine Internet-Suche bei Google kann man... Nun, mir fällt jetzt nicht direkt etwas ein. Die Features der Suchmaschine halten sich derart in Grenzen, dass ich XSS (die sich aber durch IP-Adressen gar nicht wirklich verfolgen lassen) und vergleichbare Sicherheitslücken sicher ausschließen kann. Ebenso SQL-Injections. Ein einziges Eingabefeld lässt sich mit vertretbarem Aufwand gegen alle bekannten Sicherheitsprobleme absichern. Zumindest ungleich einfacher als die Features von YouTube.

Warum also begründet Google die Protokollierung von Suchanfragen damit, dass man auch ein Dreivierteljahr später noch wissen muss wer was gesucht hat um "Missbrauch und Angriffe" zu erkennen?

Im Gegenzug frage ich mich, warum ist dies bei YouTube anders? Warum ist das Hochladen und Veröffentlichen bei YouTube kein so großes Sicherheitsrisiko wie das Stellen einer Suchanfrage bei Google?

Ich finde das Schizophren und die Begründung mit der Sicherheit ist Heuchelei.
Bei uns wird normalerweise keine IP-Adresse gespeichert. Kunden können auf Wunsch Logfiles über maximal 10 Tage erzeugen. Wenn nicht explizit vom Betreiber aktiviert, dann auch das ohne IP-Adresse.

Heute fiel mir eine sehr unschöne Sache bei .org-Domains auf. Registriert man eine solche Domain und setzt Nameserver-Einträge, die ebenfalls unter .org laufen, dann ruft die .org-Registry die IP-Adressen dieser Nameserver ab und speichert die. Diese werden dann zusammen mit der NS-Antwort als "Additional Section" an den anfragenden Client übertragen.

Das Ganze ist eine eigentlich nette Service-Leistung und klingt auf den ersten Blick plausibel.

Das Problem beginnt allerdings dann, wenn sich die IP-Adressen der Nameserver ändern. Bei uns wurde einer der drei Name-Server vor über einem halben Jahr entfernt und ein zweiter letzte Woche. Die .org-nameserver liefern aber noch immer unbeeindruckt die alten Adressen aus. Das führt dazu, dass unsere .org-Domains ohne unser Wissen jetzt nicht mehr nur schlecht sondern sogar sehr schlecht erreichbar waren.
Durch eine Änderung der Nameserver kann man erreichen, dass diese IP-Adressen neu angefragt werden. Wie man diesen Vorgang für die einmal irgendwann eingetragenen DNS-Server-Namen macht, ist mir schleierhaft.

Ich hatte mir heute den Tag über Gedanken über ein mögliches DoS-Angriffs-Szenario gemacht, aber kein wirkliches gefunden. Ich hab aber immer noch das Gefühl, dass man das DoS'en kann.

Ich komme mir grade vor als hätte ich ein paar Jahre hinterm Mond gelebt. Und zwar war mir die Existenz von CSS »block formatting contexts« völlig fremd.

Für meine Leser, von denen ich erwarte, dass es ihnen genauso geht, kurz ein Abriss:
Wenn man ein Element mittels float: left links ran kleben will, ist das einfach. Will man aber dieses float mittels clear: left wieder aufheben, dann fängt der nachfolgende Text erst unter der meistens vorhandenen linken Sidebar an. Zudem macht Internet-Explorer (< 7) gerne mal sehr komische Dinge bei einem traditionellen Sidebar-Layout.

Auf der Suche nach einer Lösung bin ich heute darauf gestoßen, dass man ein div auch in einen eigenen Formatierungs-Kontext setzen kann, innerhalb dessen beliebige clear-Statements möglich sind ohne das ganze Layout zu zerstören.

So einfach geht's: Dem Inhalts-div einfach overflow: hidden mit auf den Weg geben. Natürlich kann diese Eigenschaft Nebenwirkungen haben. Z.B. wenn man ein Element hat, das potenziell breiter ist als das Browser-Fenster. Sofern man aber die Größe des div nicht festlegt, sollte man oftmals gar keine Nebenwirkungen bekommen.
Der Internet-Explorer möchte (mittels conditional comments) noch zusätzlich ein float: left bekommen, damit das so funktioniert. Aber dann spielt auch der mit.

Die Lösung habe ich auf zahlreichen CSS-Hilfe-Seiten gefunden, eine Seite die es so hinbekommen hatte, dass ich es verstanden hab ist z.B. diese hier.

Gestern habe ich vom neuen CAcert Assurer Test gelesen:

To meet the increased demands on quality assurance due to the CAcert Systems Audit, which is needed to be included in Mozilla’s browsers, CAcert has decided to initiate a Challenge for all for Assurers.
To be an Assurer, you will need to reach 100 assurance points, and you will have to pass the Assurer Challenge. The assurer challenge and training system called CATS is so now avaliable. Under http://wiki.cacert.org/wiki/AssurerChallenge you can find the infos how to join and participate.

Natürlich war ich gleich neugierig und habe den Test absolviert. Da ich schon mehrfach auf Fachmessen für das CAcert-Projekt am Stand tätig war, war der Test inhaltlich machbar. Zeitbedarf: deutlich unter 10 Minuten.

Das Problem an der Sache begann danach. Um das Zertifikat »Certified CAcert Assurer« als PDF ausgestellt zu bekommen, muss man eine möglichst verschlüsselte und zwingend mit seinem X.509-Client-Zertifikat signierte E-Mail an CAcert senden.
Und eben das ist mit KMail zur Zeit eine völlige Katastrophe. Zeitbedarf für mich: 1 Tag. ;-)

Der Reihe nach:
KMail benutzt gpgsm zur Verarbeitung von S/MIME. Das Frontend Kleopatra erlaubt das halbwegs komfortable Einfügen meines Zertifikats in gpgsm. Damit gpgsm überhaupt irgendwelche Zertifikate benutzt, will es eine CRL konsultieren:

gpgsm[12626]: can't connect server: `ERR 50331917 can't exec `/usr/bin/dirmngr': Datei oder Verzeichnis nicht gefunden'
gpgsm: can't connect to the dirmngr: IPC "connect" Aufruf fehlgeschlagen
gpgsm: certificate #04BD1F/1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA
gpgsm: Die CRL konnte nicht geprüft werden: Kein Dirmngr
gpgsm: error creating signature: Kein Dirmngr <GPGSM>

CRLs sind eigentlich grundsätzlich sinnvoll, aber nicht bei gpgsm. Um nämlich bei gpgsm eine CRL zu benutzen, braucht man dirmngr. dirmngr braucht dazu aber auch OpenLDAP und man muss beide Kollegen manuell konfigurieren. Es gibt zumindest bei Gentoo keine dafür brauchbare Standard-Konfiguration.

Also will man bei gpgsm lieber auf eine CRL verzichten. Dazu muss man die Option disable-crl-checks in die Datei ~/.gnupg/gpgsm.conf eintragen.

Das nächste Problem sieht so aus:

gpgsm: Fingerprint=13:5C:EC:36:F4:9C:B8:E9:3B:1A:B2:70:CD:80:88:46:76:CE:8F:33
gpgsm: DBG: BEGIN Certificate `issuer':
gpgsm: DBG: serial: 00
gpgsm: DBG: notBefore: 2003-03-30 12:29:49
gpgsm: DBG: notAfter: 2033-03-29 12:29:49
gpgsm: DBG: issuer: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA
gpgsm: DBG: subject: 1.2.840.113549.1.9.1=#737570706F7274406361636572742E6F7267,CN=CA Cert Signing Authority,OU=http://www.cacert.org,O=Root CA
gpgsm: DBG: hash algo: 1.2.840.113549.1.1.4
gpgsm: DBG: SHA1 Fingerprint: 13:5C:EC:36:F4:9C:B8:E9:3B:1A:B2:70:CD:80:88:46:76:CE:8F:33
gpgsm: DBG: END Certificate
gpgsm: after checking the fingerprint, you may want to add it manually to the list of trusted certificates.
gpgsm: Interaktives vertrauenswürdig-Markieren ist in gpg-agent ausgeschaltet
gpgsm: error creating signature: Nicht vertrauenswürdig <GPG Agent>

Der hervorgehobene Teil führt zum Ziel; man muss in der Datei ~/.gnupg/gpg-agent.conf die Zeile allow-mark-trusted eintragen.

Damit der gpg-agent das auch weiß, muss er neu gestartet werden. Überflüssig zu erwähnen, dass natürlich alle Programme, die den gpg-agent verwenden möchten auch neu gestartet werden sollten. Insbesondere gilt das bei KDE und KMail so, dass KDE neu gestartet werden muss.

Nach dieser Prozedur fragt gpg-agent bei Bedarf in kaputtem UTF-8 nach, ob das Zertifikat okay ist. Bestätigt man das, stürzt er erst einmal ab:

*** glibc detected *** gpg-agent: free(): invalid next size (fast): 0x000000000065d190 ***
======= Backtrace: =========
/lib/libc.so.6[0x2ac27fb11b7d]
/lib/libc.so.6(cfree+0x76)[0x2ac27fb13896]
gpg-agent[0x415452]
gpg-agent[0x409649]
gpg-agent[0x428a38]
gpg-agent[0x40867c]
gpg-agent[0x407851]
/lib/libc.so.6(__libc_start_main+0xf4)[0x2ac27fac01f4]
gpg-agent(realloc+0x1e1)[0x4053c9]
======= Memory map: ========
[...]

Beim nächsten Versuch sollte aber alles soweit klappen.


Damit konnte ich dann eine X.509-signierte und -verschlüsselte E-Mail senden.

Am nächsten Morgen ...

Heute war dann die Antwort von CAcert da, eine E-Mail mit ~140 KB. KMail sagt dazu:

Verschlüsselte Nachricht (keine Entschlüsselung möglich)
Grund: Nicht unterstütztes Verfahren
smime.p7m
S/MIME Encrypted Message

Ende der verschlüsselten Nachricht

Um dieses Problem weiter einzugrenzen habe ich die Datei smime.p7m gespeichert und mit gpgsm auf der Konsole versucht, weitere Infos einzuholen:

$ gpgsm -v --decrypt smime.p7m
gpgsm: unsupported algorithm `1.2.840.113549.3.2'
gpgsm: (Dies ist der RC-2 Algorithmus)
gpgsm: message decryption failed: Nicht unterstütztes Verfahren <GPGSM>

Eine kleine Internet-Such-Aktion später war klar: gpgsm unterstützt den alten RC2-Algorthmus schlicht und einfach nicht mehr. Thunderbird meint aber leider viel zu oft, diesen benutzen zu müssen.

Einzige mir sinnvoll erscheinende Lösung: Ich habe Mozilla Thunderbird installiert, dort meinen IMAP-Zugang konfiguriert, mein X.509-Zertifikat importiert und mit diesem die E-Mail geöffnet und das angehängte PDF gespeichert.


Nach knapp 10 Minuten Assurer-Prüfung und etwa einem Tag Kampf mit S/MIME bin ich nun also offiziell Certified CAcert Assurer Nummer 78. ;-)

(Wer nichts sieht, verpasst ein geiles YouTube-Video)

Heute kam in der Murrhardter Zeitung (und vermutlich auch in der Backnanger und Winnender Zeitung sowie in den Stuttgarter Nachrichten) dieser Artikel (alles unwichtige ausgegraut):



Und da sind mir als allererstes drei Dinge ins Auge gesprungen: Die Überschrift, das Bild und die Bildunterschrift. Von diesen dreien passen beliebige Kombinationen von zwei Dingen schon nicht mehr zusammen. Hier kurz was da zu sehen ist:

Überschrift

»Jugendliche vor Pornos im Internet schützen«

Bild

Ich kenn mich damit ja nicht so aus, aber es handelt sich defnitiv nicht um einen PC sondern um einen C64 oder einen Amiga mit zeitgeschichtlich passendem Joystick, Monitor und passender Maus (also vermutlich Amiga). Zu deutsch: Die Kinder auf dem Bild sind vermutlich heute erwachsen. :) Der Inhalt des Monitors ist deutlich sichtbar ein Jump'n'run Spiel. Pr0n sieht anders aus.

Bildunterschrift

»Leichte Verführung im Internet: Jugendliche beim Surfen«

Ich glaube weitere Kommentare erübrigen sich.

In den letzten Tagen gab es zwei interessante Vorkommnisse mit Mailinglisten unserer Fachschaft. Es sind jeweils Adressen auf der Mailingliste gelandet, die da nicht hin gehören.

1. Die -subscribe-Adresse befand sich plötzlich auf der Mailingliste

   
   Bei jeder Mail an die Mailingliste bekam der Absender eine »please confirm that you want to subscribe to ...«-Mail. Auslöser des Problems war eine Spam-Mail, die als Absender und als Empfänger die -subscribe-Adresse gesetzt hatte.



2. Ein unbedarfter Empfänger irgendwo in den USA war plötzlich auf unserer (deutschsprachigen) Mailingliste

   
   Auslöser war sein Autoresponder, der die Nachricht beantwortet hat. Der Request wurde von einer Spam-Mail provoziert und sein autoresponder hat ihn auf die Liste gesetzt.

Mir gefallen diese Vorkommnisse gar nicht. Eigentlich bin ich ein Freund von E-Mail-basierten Mailinglist-Managern (wie z.B. ezmlm oder der von uns benutzte couriermlm) da sie für den Benutzer einfach (ja, ich weiß, sichtweise) zu benutzen sind und vor allem kein Medienbruch stattfindet. Diese beiden Vorkommen sind aber der Beweis dafür, dass das mit dem double-opt-in so ganz trivial auch nicht über E-Mail machbar ist.

Ich seh schon den Kommentar im Voraus, dass couriermlm doch eigentlich bitte ein »YES« in der Betreffzeile haben möchte wenn man sich einträgt. Nur kann man diese Option auf einer überwiegend deutschsprachigen Mailingliste glatt mal vergessen. Schon alleine die Verwendung eines E-Mail-basierten Mailinglisten-Managers stellt einen gewissen Teil unserer Informatik-Studenten (!) vor ungeahnte Probleme. Das einfache Antworten auf die Mail konnten wir mit einer detaillierten, deutschsprachigen Anleitung hin bekommen, aber mit dem YES-eintragen, das hat nicht geklappt. ;-)
Aus diesen Gründen betreiben wir die Mailingliste mit ausgeschaltetem »YES«-Zwang, was uns jetzt vor das Problem stellt, dass Leute auf der Liste stehen, die das gar nicht wollen...

Jeder, der den Titel dieses Blogpostings oder Teile daraus liest, schreibt oder danach sucht, ist ein Schwerverbrecher, Terrorist, Journalist oder freier Mensch. Egal was davon: Er gehört gefunden, inhaftiert, exekutiert und vor allem überwacht und reglementiert.

So in etwa muss man sich das meiner Meinung nach in der Praxis vorstellen, was EU-Kommissar Franco Frattini momentan ausbrütet.

Golem berichtet:

Der für Justiz und Sicherheit zuständige EU-Kommissar Franco Frattini will prüfen, wie mit technischen Mitteln verhindert werden kann, dass Menschen "gefährliche Worte" wie beispielsweise "Terrorismus" oder "Bombe" im Internet benutzen oder nach diesen suchen.

Mein Vorschlag: Das deutsche Innenministerium soll den angeblich einsatzbereiten Bundestrojaner mit all seinen Eigenschaften (auf jedes System installierbar, nicht entdeckbar, ...) für teuer Geld an die EU verkaufen. Über diesen kann die EU dann jeden identifizieren der solch böse Sachen macht.
Dann kann Herr Schäuble das vorauszusehende Nichtfunktionieren auf die Unfäghigkeit der EU-Ermittler schieben und den Inlandseinsatz klammheimlich abblasen.

Alle wären fein raus und die Steuerverschwendung wäre auf die ganze EU verteilt.

Ich denke, dass das Innenministerium diesen Vorschlag durch heimliche Bespitzelung meiner Blog-Besucher bestimmt finden wird.

*pust* [...] *hust*, *röchel*
Wow, ist das eingestaubt hier. Sorry, war anderweitig beschäftigt.

Fabians Blog-Eintrag von neulich möchte ich glatt mal aufgreifen.

Wenn mein Jabber-Status (der auch meistens stimmt!) auf Away bzw. N/A steht, dann bin ich nicht da. Manchmal setze ich den den Status auch von Hand auf DnD oder N/A. Auch dann bin ich zwar oft physisch am Rechner aber eben nicht gewillt, mich mental auf leichte Konversation einzustellen. Meistens arbeite ich irgend etwas. :)

Wenn mein Status also nicht auf Online steht, dann steht es jedem frei, mir dennoch Nachrichten zukommen zu lassen. Ob ich gleich oder später darauf antworte, hängt aber maßgeblich vom Inhalt ab. Auf ein »hi« ohne weiteren Content werde ich in der Regel 3 Stunden später nicht mehr antworten. Auch wenn ich beschäftigt bin, unterbreche ich meine Arbeit normal frühestens für eine Antwort auf die Nachricht nach dem »hi«. Und wer einen komplexen oder wichtigen Sachverhalt zu sagen hat, der ist in der Regel sowieso mit E-Mail oder gar Bugtracker besser bedient, denn nur da sind die Sachen eine gewisse Zeit später immer noch da.

Das jetzt nicht akut auf einen oder wenige Fälle bezogen, ich denke viele könnten sich angesprochen fühlen. Es ist eher eine allgemeine Feststellung, dass sich Leute offenbar wenig Gedanken machen, wie das auf mich wirkt, wenn ich zurück an den Rechner komme und 10 mal »hi« ohne weiteren Inhalt vorfinde.