SSL3 ist unsicher. Das ist nicht neu – aber heute Nacht hat Google uns mit dem „Poodle“-Angriff eindrucksvoll gezeigt, wie unsicher SSL3 ist. Es wird also Zeit für einen lauten Aufschrei: Admins, konfiguriert eure Server endlich sicher! Geschäftsführer, sorgt für eine sichere IT in euren Unternehmen!
In meinem Vortrag auf der diesjährigen Herbstakademie der Deutschen Stiftung für Recht und Informatik (DSRI) habe ich dargelegt, welche technischen Mindeststandards Web-, Mail- und ähnliche Server aus rechtlicher Sicht erfüllen müssen (zum Vortrag; der Beitrag ist aktualisiert in CR 2014, 726 – 732 erschienen). Dazu gehören unter anderem der Verzicht auf geknackte Algorithmen wie RC4 und MD5, die Nutzung von Perfect Forward Secrecy – und der Verzicht auf das unsichere SSL3.
Das reine Angebot unsicherer Verfahren gefährdet alle Nutzer
Bereits wenn ein Server unsichere Verfahren aus vermeintlichen Kompatibilitätsgründen „auch“ anbietet, gefährdet er alle seine Nutzer: Denn dieses „Auch“-Angebot ermöglicht Downgrade-Angriffe, durch die Nutzer von eigentlich sicheren Verschlüsselungsverfahren auf unsichere umgestellt werden. Dabei braucht praktisch niemand mehr SSL3 – der Internet Explorer 6 unter Windows XP, ja. Aber ein Windows XP hat ohnehin nichts mehr am Internet zu suchen, seit es keine Sicherheits-Updates mehr gibt. Und den Internet Explorer 6 benutzt sowieso kaum mehr jemand. (Wenn doch, wird es Zeit, diese Leute zum Update zu nötigen. Etwa durch Inkompatibilität.)
Doch was macht die Praxis? Oftmals: Mist.
Schaut man sich nur das Online-Banking der 100 größten Banken in Deutschland an, schaudert es einen: Nur neun der 76 Banken, die ein Online-Banking haben, (11,8 Prozent) nutzten zeitgemäße Verschlüsselung, die auch bei Nutzung des Internet Explorers (in moderner Version) eine zeitgemäße Verschlüsselung mit Perfect Forward Secrecy bietet (ECDHE mit AES). 25 weitere Banken (32,9 Prozent) boten zumindest für Nutzer anderer moderner Browser PFS (DHE mit AES), eine davon allerdings mit einem abgelaufenen Sicherheitszertifikat (zwischenzeitlich behoben). 40 Banken (52,6 Prozent) verwendeten als Verschlüsselungsverfahren dagegen das veraltete RSA mit AES. Zwei Banken nutzten gar standardmäßig RC4 – und insgesamt 78,4 Prozent der Banken unterstützen RC4, obwohl das Verfahren bereits seit Jahren nicht mehr für vertrauliche Kommunikation eingesetzt werden darf.
Schlechte Verschlüsselung ist gefährlicher als gar keine
Das Fatale an dieser Schlamperei ist: Der normale Nutzer bemerkt nichts davon. Weil gerade Banken viel Geld für „Extended Validation“-Zertifikate ausgeben, erscheint ein grünes Schloss in der Browser-Leiste. Der User denkt: Super, sicher! Und gibt seine vertraulichen Daten ein. Aber erst wenn er z.B. das Firefox-AddOn „Calomel“ installiert, stellt er irritiert fest, dass neben dem grünen Schloss ein rotes Schild prangt: „Very weak!“ ist die Verschlüsselung nämlich allzu oft. Und die Daten möglicherweise geklaut.
Es lässt hoffen, dass das bayerische Landesamt für Datenschutzaufsicht letzten Monat angefangen hat, automatisiert und anlasslos zu überprüfen, ob Mail-Server bayerischer Unternehmen zumindest gewissen Mindestanforderungen genügen. (Das kann das Amt jetzt machen, nachdem bayern.de vor kurzem mit nur 15 Jahren Verspätung auch endlich STARTTLS eingeführt hat.) Die Bayern haben angekündigt, dass sie die Software an die anderen Aufsichtsbehörden weitergeben werden. Und dass sie schon etwas Neues in der Pipeline haben: die Prüfung von HTTPS.
Seit heute Nacht gibt es ein weiteres Argument, diese Prüfungen zu forcieren. Und für Unternehmen eins, endlich aufzuwachen und dem „blauen Brief“ der Aufsichtsbehörde zuvorzukommen.
Siehe auch
Unternehmens-IT absichern: BND will Sicherheitslücken ausnutzen
Matthias Bergt: „Verschlüsselung nach dem Stand der Technik als rechtliche Verpflichtung”, CR 2014, 726
