Bernds Blog

Ich habe soeben meinen ICQ-Account gelöscht.

Nachdem ich jetzt mindestens 8 Jahre lang keinen praktischen Nutzen mehr aus ICQ gezogen habe wird es Zeit, diese Altlast los zu werden.

Die Tage kam bei schokokeks.org die Notwendigkeit nach einem zusätzlichen Server auf, der nichts anderes machen sollte als Backups von einigen bestehenden Maschinen entgegen zu nehmen. Der Server soll als virtuelles Gastsystem betrieben werden, da die erwartete Last minimal ausfällt. Da wir stets versuchen, IPv4-Adressen nicht zu vergeuden, wollte ich diesen Server als IPv6-only-System in Betrieb stellen.

Das hat grundsätzlich gut geklappt, es gab aber einige Stellen die (für mich unerwarteter Weise) Probleme bereitet haben.

1. OpenVPN kann nicht über IPv6. Mit der Version 2.3 soll das angeblich anders werden, die gibt es aber bisher noch nicht. Meine Lösung war, dass ich eine private IPv4-Adresse eingerichtet habe, die der physikalische Server auf einen anderen Server routet, der ebenfalls eine passende private IPv4-Adresse hat. Dadurch kann OpenVPN über diese IPv4-Verbindung kommunizieren.


2. Die normalen Gentoo-Mirror-Dienste beachten kein IPv6 und liefern im Round-Robin einfach irgendwas zurück, was ich dann nicht aufrufen kann. :( Die Lösung war, gezielt SYNC-Server und Distfiles-Mirror einzutragen die IPv6-Verbindung liefern. Die Listen gibt es hier (sync-Mirrors) und hier (Distfiles-Server). Jeweils die mit Sternchen sind IPv6-fähig.


3. Wir betreiben normalerweise lokale DNS-Resolver auf jedem Server. Für diesen speziellen Zweck ist das okay, aber man kann halt nur Namen auflösen, die auch über IPv6-fähige DNS-Server angeboten werden. IPv6-Paradebeispiel Heise online geht z.B. nicht, da deren DNS-Server keine IPv6-Adressen haben. Um etwas mehr Möglichkeiten zu haben, kann der Google-Public-DNS benutzt werden: 2001:4860:4860::8888.

Letztlich ist OpenVPN der einzige Grund, dass auf der Maschine überhaupt eine IPv4-Adresse eingerichtet ist. Und das soll sich ja angeblich mit dem nächsten Release, für das bereits ein RC angeboten wird, ändern. Ich bin jedenfalls gespannt.

Unsere normalen Serverdienste betreiben wir schon seit Jahren im Dualstack. Vor einigen Wochen wurde der Linux-Default-Resolver auch so geändert, dass er IPv6 bevorzugt, da hatten wir ein Localhost-Problem (Zugriffe auf localhost kamen dann von ::1 und nicht mehr von 127.0.0.1, da mussten einige Konfigurationen angepasst werden). Aber ansonsten bereitet uns der Dualstack-Betrieb keine Schwierigkeiten.

Wir auf dem Dorf sind ja schon länger etwas abgeschlagen, was eine moderne Internet-Verbindung angeht.

Auch wenn ich es komischer Weise stark verzögert überhaupt mitbekommen habe: Es gibt eine Linderung der Probleme (und untypischer Weise sogar kostenlos, unbürokratisch und bei neuen Anschlüssen als Standardvorgabe).

Seit heute wurde unser DSL-Zugang vom Schmalspur-DSL (768 kBit) auf DSL 2000 RAM umgestellt. RAM steht für "rate adaptive mode" und bezeichnet das was in allen modernen Übertragungsverfahren gemacht wird, die Verbindungs-Geschwindigkeit wird von den Geräten individuell ausgehandelt.

So wurden aus den von der Telekom konservativ und fest eingestellten 768 kBit jetzt real erreichbare 1886 kBit (mit einer FritzBox 7170, es soll angeblich auch bessere Modems geben). Mein Netz ist also jetzt offiziell gepimped und ich kann jetzt zu Recht sagen dass wir hier Internet-Zugang haben. Laut Bundesregierung haben wir damit sogar Breitband-Internet.

(Und mal unter uns: Es macht einen riesigen Unterschied ob durchschnittliche YouTube-Videos langsamer oder schneller geladen werden als die Abspielgeschwindigkeit.)

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.