Laut einem Artikel bei heise.de plant die EU Kommission, nachdem sie das Urteil des Europäischen Gerichtshofes zur Vorratsdatenspeicherung gelesen hat nicht die Vorratsdatenspeicherung in Europa nochmal anzupacken.
Ich werde nach dem Urteil des Europäischen Gerichtshofes keinen neuen Gesetzentwurf mehr zur Vorratsdatenspeicherung vorlegen.
Allerdings lässt sich Frau Malmström eine Hintertür für die Zukunft offen. Zitat:
Wenn es überhaupt noch irgendwann zu einer neuen EU-Richtlinie kommen sollte, dann erst, wenn die Gesetzgebung zum Datenschutz verabschiedet ist.
Eine weitere Sache lässt noch aufmerken. So heißt es in dem Artikel unter anderem:
Malmström verwies darauf, dass alle Mitgliedsstaaten mit Ausnahme Deutschlands derzeit eigene Vorgaben zur Vorratsdatenspeicherung hätten. Damit sei sichergestellt, dass es auch künftig möglich ist, “Verkehrsdaten” zur Verbrechensaufklärung in den einzelnen Ländern der Union aufzubewahren und zu nutzen.
Man will also anscheinend in Brüssel nicht darauf hinwirken dass die Mitgliedsstaaten ihre nationalen Regelungen, die gegen europäiasches Recht verstoßen aufheben, man will sie einfach beibehalten. So setzt man sich über die Entscheidung des Europäischen Gerichtshofes einfach hinweg.
Der kleine Email-Anbieter Posteo hat heute seinen ersten Transparenzbericht zu Datenabfragen staatlicher Behörden veröffentlicht. Der Bericht ist hier einsehbar.
In dem Transparenzbericht von Posteo ist auch eine versuchte Nötigung, sowie Anstiftung zum Rechtsbruch durch Beamte des Staatsschutzes dokumentiert.
Alle anderen deutschen Email und Internet-Provider haben sich bisher nicht getraut derlei Berichte zu veröffentlichen. Umso erfreulicher ist es das nun Posteo den ersten Schritt gemacht hat und damit Standards für die Branche setzt. Die anderen Anbieter werden jetzt hoffentlich nachziehen.
Als erstes hat die Telekom einen ähnlichen Bericht veröffentlicht und dabei schonmal gezeigt wie man es nicht machen sollte. Der Telkombericht enthält zwar Angaben über die beantworteten verschiedenen Gesuche (Bestandsdatenauskunft, IP Auskunft, Komplett-Überwachung,…) jedoch keinerlei Angaben darüber wieviel Gesuche gestellt wurden, vieviele davon Abgelehnt wurden und aus welchen Gründen. Gerade diese Daten geben aber Indizien darüber wie sehr ein Anbieter versucht die Daten seiner Kunden zu schützen (oder eben wie willfährig man Anfragen abnickt und beantwortet auch wenn die Anfrage formal nicht korrekt gestellt wurde oder die Abgefragten Daten schlicht weg illegal erhoben werden sollen, weil z.B. ein Richterlicher Beschluß fehlt.
Die Daten von Posteo legen nahe dass die deutschen Behörden in den meisten Fällen noch nicht mal in der Lage sind korrekte Anfragen an die Provider zu übermitteln. Bei Poste waren zwei drittel aller Anfragen schlicht weg illegal (fehlender Richterbeschluß) oder formal nicht korrekt gestellt oder übermittelt worden.
Ich wünsche mir dass möglichst viele Anbieter dem Beispoiel von Posteo folgen und ihrerseits ähnlich detailierte Berichte regelmäßig veröffentlichen. Wer als Kunde bei einem Provider ist der das nicht macht sollte mit nachdruck einen solchen Bericht verlangen. Verweigert der Anbieter einen derartigen Bericht sollte man sich nach einem neuen Anbieter umsehen und mit seinem Geldbeutel abstimmen.
Dank an Patrik und Sabrina Löhr von Posteo für ihren mutigen Schritt einen derartigen Report zu veröffentlichen.
Wegen des Heartbleed Fehler ist gerade ein guter Zeitpunkt mal die eigene SSL config zu überarbeiten und auf den aktuellen Stand zu bringen. Daher werde ich in diesem Blogposting mal erklären wie - und was - ich da für scusiblog.org gemacht habe.
Die folgenden Anweisungen beziehen sich alle auf den webserver nginx.
HTTP Client-Anfragen auf HTTPS umleiten
## scusiblog.org http redirect server config ########################
# if someone contacts us on port 80 we redirect to https
server {
listen scusiblog.org:80;
#listen [::]:80;
server_name www.scusiblog.org scusiblog.org;
return 301 https://$server_name$request_uri;
}
###############################################################################
Die obigen 10 Zeilen definieren einen Server auf Port 80 der alle eingehenden
Anfragen dauerhaft (Return Code 301 - Moved Permanently) auf die gleichnamige
HTTPS URL verweist.
Will man auch auf IPv6 Anfragen antworten muss man Zeile 5 einkommentieren (das #-Zeichen am anfang der Zeile löschen.
HTTPS Server konfigurieren
Der folgende Abschnitt konfiguriert einen HTTPS server. Will man IPv6 Anfragen beantworten muss man Zeile 3 einkommentiren.
Die Zeile mit root legt das root-Verzeichnis fest, index legt die zu verwendenden Standard-Seiten fest.
Der Abschnitt location sorgt dafür dass auch syntaktisch nicht korrekte - aber dennoch gern genutzte - URLs zu ihrem Ziel finden.
Die Datei scusiblog_chained.crt ist das scusiblog Zertifikat (PEM encoded) mit daran anschließendem indermediate Zertifikat meiner CA.
Diese Datei erstellt man so:
Das ist oft nötig weil einige CAs zwar in den Stammzertifikaten der Browser enthalten sind aber aus verschiedenen Gründen nicht mit ihrem Stammzertifikat andere Zertifikate signieren. Es gibt noch eine Zwischenstelle, die sogenannte intermediate CA, deren Zertifikat ist vom Stammzertifikat unterschrieben, und signiert seinerseits Zertifikate von Kunden. Wenn man Kunde einer solchen CA ist, dann muss man dafür sorgen dass das Zertifikat der zwischen CA auch zum Browser des Besuchers geliefert wird. Andernfalls sucht der Browser das Zertifikat was viel Zeit (und unnötige Resourcen) beim Verbindungsaufbau kostet. Die einfache Lösung ist daher das Zertifikat der intermediate CA mit dem des eigenen Servers zusammen zu kleistern und gemeinsam dem Client zu schicken.
Protokolle und Verschlüsselungsverfahren
Als nächstes müssen noch die gewünschten Protokollversionen und die Verfahren zur Verschlüsselung konfiguriert werden. Das ist einer der eigentlich kritischen Teile.
Wir machen das in den obigen drei Zeilen. Zeile 1 legt fest welche Protokolle unser Server unterstützt. Die Reihenfolge ist auch Wichtig, sie gibt unsere Präferenz an. Je weiter links in der Zeile ein Protokoll steht desto lieber würden wir dieses nutzen. Wir wollen TLS1.2 nutzen, wenn es nicht anders geht nehmen akzeptieren wir auch TLS1.1 oder gar TLS1(.0). SSL sprechen wir gar nicht weil das signifikant kaputt ist.
Zeile 2 legt die sogenannten ciphers - also die Verschlüsselungsverfahren fest. Wie schon bei den Protokollen ist die Reihenfolge wichtig. Wir wollen ECDHE-RSA-AES256-GCM-SHA384sprechen wenn möglich. Bei diesem Verfahren sind die Schlüssel der Teilnehmer RSA Schlüssel, die Sitzungsschlüssel werden über das Deffie-Hellman Schlüsselaustauschverfahren (DHE) auf eliptischen Kurven (EC) basierend ausgetauscht. Der Transportstrom wird mit AES-128 geschützt und als absicherung gegen Manipulation wird der Galois/Counter Mode mit SHA384 verwendet. Das ist gerade State of the Art.
DH Parameter erzeugen und einstellen
Die DH Parameter werden für Verfahren die elliptische Kurven nutzen gebraucht und müssen erstmal - auf jedem System - neu generiert werden. Das macht man am besten mit dem folgenden openSSL Befehl. Das folgende Beispiel geht davon aus das ein 4096 bit Key für das System vorliegt.
Die folgende Zeile definiert die zu verwendenden Kurven.
ssl_ecdh_curve secp384r1;
Strict-Transport-Security
Strict Transport Security ist ein HTTP-Header Flag welches dem Browser signalisiert dass diese Seite nur über HTTPS geladen werden soll.
Der Parameter max-age gibt an wie lange in die Zukunft die Ansage - diese Seite nur über HTTPS zu laden - gelten soll.
31536000 Sekunden entspricht einem Jahr. Damit sorgen wir also dafür dass ein Browser ein Jahr lang nach seinem letzten Besuch scusiblog.org nur noch per HTTPS kontaktiert.
Sinnvolle Zeitspannen sind etwa 12 oder 24 Monate, respektive 31536000 oder 63072000 Sekunden.
Kürzere Zeitspannen, vor allem unter einem halben Jahr sind inakzeptabel.
Sitzungseinstellungen
Jetzt legen wir noch fest dass unser Session Cache zwischen den einzelnen Instanzen geteilt werden soll.
Die Sitzungszeit - bis ein neuer Sitzungsschlüssel ausgetauscht werden muss - stellen wir auf 10 Minuten ein.
Mit einer solchen Konfiguration hat man nach dem Stand heute eine gute und sichere SSL/TLS Konfiguration.
Vom Qualys SSL Test gibt es dann - bis zur nächsten Schwachstelle - auch die Bestnote A+.
Endlich ist es vollbracht, ich hab es endlich geschafft mein blog auf eine neue technische basis zu stellen und auf einen anderen Server umzuziehen.
Das SSL Zertifikat ist auch neu. Nein, das wurde nicht wg. Heartbleed notwendig - scusiblog.org war nie dagegen verwundbar - sondern stand eh an weil das alte Zertifikat in den nächsten Tagen ausgelaufen wäre.
Die Fingerabdrücke des neuen Zertifikats sind wie folgt:
SHA1 9E 79 0D 78 68 4C B1 C2 92 A4 2A EE 9C DC E2 DD AF F3 23 E9
MD5 8D 9B B3 50 6E 8D D8 4E 45 B6 B2 1D 67 D9 B3 2A
Jetzt muss ich noch die folgenden Aufgaben erledigen:
ein paar redirect rules schreiben damit die alten Artikel URLs weiterhin funktionieren
Der Europäische Gerichtshof hat heute die Vorratsdatenspeicherung für nicht vereinbar mit den Europäischen Gesetzen erklärt und damit die komplette Richtlinie der EU gekippt.