In den Kommentaren zur Videoüberwachung in Jena riet mir Gonzo mich mit dem Datenschutzbeauftragten des Landes in Verbindung zu setzen. Zu dem Zeitpunkt hatte ich das bereits getan und “interessante” Erfahrungen gesammelt.
Erfahrungsgemäß bieten die Datenschutzbeauftragten PGP-Schlüssel an und in der Tat fand ich auf der Kontaktseite einen zum “Download” und einen in “lesbarer” Form. Ich wähle den ersten und stutze als ich die URL sehe. Das Dokument heißt pgp_schluessel.doc und file bestätigt mir den Verdacht: pgp_schluessel.doc: Microsoft Word-Dokument. Na gut, es gibt ja noch den in lesbarer Form. Ich übergebe curl die URL und versuche das Ergebnis gleich zu GnuPG zu importieren. Doch auch hier erscheint eine Fehlermeldung. Ein Blick auf die lesbare Form enthüllt dann ein HTML-Dokument. Nachdem ich dann den Schlüssel manuell extahiert hatte, konnte ich auch meine E-Mail schreiben. Doch da hatte ich bereits einen Verdacht, wie die Antwort ausfallen würde ...
In der Tat erhielt ich nach ein paar Tagen die Antwort, dass man meine E-Mail (bzw. den Anhang) nicht öffnen könne. In den Headern der E-Mail stand etwas von Outlook und je nachdem welche Zusatzsoftware man verwendet, kann es Probleme mit den (an sich korrekt) verschlüsselten E-Mails geben. Also schickte ich die E-Mail nochmal und nutzte eine ältere Methode (Inline-Verschlüsselung), die von allen Programmen erkannt wird. Ihr dürft jetzt dreimal raten, wie die Antwort ausfiel. 
Im Anschluss wandte ich mich an das ULD in Schleswig-Holstein und bekam von dort eine sehr detaillierte, ausführliche Antwort.
Wolltest du schon immer mal auf leicht verständliche Weise erfahren, wie der Verschlüsselungsalgorithmus AES funktioniert? Enrique Zabala hat seine Flashanimation zur Funktionsweise nochmals verbessert. Diese Animation erklärt Schritt für Schritt den Ablauf des Algorithmus’ und ist eine gute Einführung in das Thema. Unten seht ihr einen Screenshot.
Du hast ein Konto bei Google Mail? Du loggst dich immer per SSL ein? Du denkst, niemand sonst kann deine E-Mails lesen? Falsch!
Bereits im letzten Jahr zählte der Hack zu den Top 5. Dabei ist es im Allgemeinen so, dass man von der Webseite, bei der man sich einloggt, einen Session-Cookie bekommt. Ein Angreifer fängt diesen ab und kann nun selbst mit dem Account arbeiten. Eigentlich sollte die Verschlüsselung per SSL/TLS die Sachen geheim halten. Aber:
[...] The JavaScript code uses an XMLHttpRequest object to make HTTP requests in the background. These are also SSL encrypted by default - but they become unencrypted if SSL fails.
When you open your laptop and connect to a WiFi hotspot, it usually presents you with a login page, or a page that forces you to accept their terms and conditions. During this time, SSL will be blocked. Gmail will therefore backoff and attempt non-SSL connections. These also fail - but not before disclosing the cookie information that allow hackers to sidejack your account.
Dies schreibt Rober Graham in seinem Eintrag More SideJacking
. Mike Perry, einer der Entwickler von Torbutton, fand heraus, dass einzig der Cookie mit dem Namen GX zur Authentifizierung benötigt wird. Dieser wird unabhängig von vorhandener Verschlüsselung gesendet. Weiter lässt sich der Cookie durch einen CSRF-Angriff über eine beliebige Webseite abfragen. Daher ist es äußerst empfehlenswert, die Cookies direkt nach Beenden von Google Mail zu löschen.
Die Forscher haben Google Mail als Beispiel benutzt. Natürlich gibt es viele andere Webseiten da draußen bei denen ein ähnlicher Angriff genauso gut funktioniert.
via Wired Blog
Das Thema Disclaimer an E-Mails ist wahrscheinlich vielen von euch hinlänglich bekannt. Heute bekam ich eine E-Mail mit einem doch sehr interessanten Disclaimer:
From: foobar
Date: Wed, 5 Dec 2007 12:13:45 +0100 (CET)
To: jens
Subject: Information des FRZ
;; This buffer is for notes you don’t want to save, and for Lisp evaluation.
;; If you want to create a file, visit that file with C-x C-f,
;; then enter the text in that file’s own buffer.
Hallo,
wir wurden heute von ...
Ich glaube, da muss jemand noch lernen, mit dem Emacs E-Mails zu schreiben. 
Heute versuchte ich mit einem Bekannten M$ Outlook einzurichten. Er hatte mir bereits zu Anfang erzählt, dass er einige spezielle Features sucht und ich ahnte schon, dass das nicht möglich ist. Dieses bestätigte sich durch Googeln. Irgendwann meinte er frustriert:
Das ist ja wie ein russisches Radio. Die kennen auch nur Ein und Aus.
Das muss ich mir merken. 
Gestern war ein ziemlich langer Tag. Ich stand gegen um zwei Uhr morgens auf und war den Tag über reichlich beschäftigt. Als ich dann am Abend genügend Müdigkeit angesammelt hatte, kam ich auf die glorreiche Idee, die Inhalte einer mbox-Datei nach /var/mail/jens zu kopieren. Direkt nachdem ich echo /foo/bar/baz > /var/mail/jens eingegeben hatte, fiel mir auf, dass das doch eine sehr blöde Idee war ...
Hin und wieder schreibe ich was zum Spamaufkommen. Seit einiger Zeit fiel mir auf, dass ich wesentlich weniger Spam bekomme. Bis August lag das tägliche Aufkommen zwischen 600 und 1.000 E-Mails pro Tag. Seitdem ist die Rate auf ca. 100 pro Tag gefallen. Das war natürlich irgendwie komisch. Zuerst dachte ich, dass vielleicht irgendwas am Mailsetup kaputt ist. Doch nachdem ich alles geprüft hatte, blieb nur noch der Provider als “Schuldiger”. Auf eine Nachfrage wurde in der Tat bestätigt, dass sie eigene Schutzmechanismen eingebaut haben. Diese prüfen und sperren im wesentlichen die Hostnamen und Adressen ohne DNS-Auflösung. Tja und das bewirkt hier offensichtlich Wunder.
Ich bin mal gespannt, ob in drei Jahren wieder das alte Niveau erreicth wurde. Die obige Grafik zeigt in etwa den Verlauf der einkommenden Spammails seit 2004 an. Dort sieht man auch recht eindrucksvoll den Einbruch, der durch die neuen Maßnahmen bedingt ist.
