Sicherheit und Kompatibilität
Disclaimer:
Wenn ihr die die Begriffe “eMail” und “sichere Kommunikation” in einem Zusammenhang hört oder lest (und nicht direkt dazu gesagt wird, dass bei eMail eben eine Ende-zu-Ende-Verschlüsselung fehlt), könnt ihr aufhören zuzuhören / zu lesen oder wahlweise auch die Bullshit-Bingo-Karte zücken und mit dem Ausfüllen beginnen.
eMail ist nicht sicher, jedenfalls nicht ohne PGP oder S/MIME, weil es eben an einer Ende-zu-Ende-Verschlüsselung mangelt (das gilt nebenbei auch für De-Mail, egal ob im Gesetz was anderes steht). Die ganze Verschlüsselung die wir heutzutage machen dient nur dazu a) die Passwörter zu schützen und b) es Dritten nicht ganz so leicht zu machen die Mails während sie von Server zu Server übertragen werden mitzuschneiden. Mindestens der Betreiber Eures Mailservers und der Eurer Kommunikationspartner könnten in die Mails reinschauen. Bei eMail ist nicht garantiert, dass der Absender wirklich derjenige ist der er zu sein vorgibt, die Kommunikation ist nicht vertraulich, es ist nicht garantiert dass die Nachricht in einer bestimmten Zeit oder überhaupt ihr Ziel erreicht, es ist nichtmal garantiert dass es in solchen Fällen eine Fehlermeldung gibt
Das ist alles sehr traurig, dass hier in über 30 Jahren keine Verbesserungen stattgefunden haben, aber das ist leider der Stand der Dinge. Computer-Standards aus den 80er Jahren liefern eben auch 80er-Jahre-Ergebnisse.
Wir haben in den letzten zwei Jahren unser Setup was TLS angeht mehrfach anpassen müssen, weil kryptographische Standards ins Wanken gerieten oder gebrochen wurden und es ist auch noch kein Ende in Sicht. Dabei müssen wir oft auch eine Abwägung treffen was wichtiger ist: Sicherheit oder Kompatibilität.
Vor drei Jahren als die BEAST-Attacke veröffentlich wurde, haben wir z.B. eine ganze Weile wieder auf die bereits schwächelnde RC4-Verschlüsselungsmethode gesetzt, weil es leider zum Teil recht lange dauerte bis die Hersteller von Browsern und Mail-Clients Maßnahmen gegen die BEAST-Attacke ergriffen haben. Vor zwei Jahren mussten wir dann aber Apple-Clients notgedrungen abklemmen, denn inzwischen schwankte RC4 immer mehr und Apple hat sich mit dem nötigen Update leider unglaublich lange Zeit gelassen. Ebenfalls abklemmen mussten wir Windows XP, das keine moderneren Verschlüsselungsverfahren als 3DES und RC4 beherrscht. Diese Verfahren noch länger zu unterstützen hätte alle User (nicht nur die von Apple-Software und Windows XP) dem Risiko ausgesetzt, dass Angreifer die Verhandlung ihrer Software mit unseren Servern über die Verschlüsselung so stören, dass am Ende RC4 verwendet wird.
Letztes Jahr passierte dann ähnliches mit SSL 3.0, das mit der POODLE-Attacke endgültig kaputt war und abgeschaltet werden musste, damit Angreifer die Verhandlungen zwischen Clients und Servern nicht mehr so stören können, dass diese von TLS 1.2, 1.1 oder 1.0 auf SSL 3.0 zurückfallen. Wir haben daraufhin SSL 3.0 auf unseren Servern abgeschaltet. Anders als bei RC4 hatten wir dabei nicht mit ernsthaften Kompatibilitäts-Problemen gerechnet, denn SSL 3.0 ist ein Standard von 1996 und nachdem in den letzten drei Jahren immer wieder diskutiert wurde, dass von TLS 1.0 (1999) und 1.1 (2006) dringend auf TLS 1.2 (2008) migriert werden muss, gingen wir nicht mehr davon aus, dass irgendjemand noch ernsthaft nur SSL 3.0 unterstützt. (Wir hatten unsere Befürchtungen, rechneten aber nicht damit dass es irgendwelche weit verbreiteten Clients treffen würde.)
Wir waren einigermaßen schockiert, als uns dann doch einige Mails erreichten aus denen klar hervorging, dass wir damit Microsoft Outlook for Mac 2011 und Outlook for Mac for Office 365 (beides aktuelle Produkte) abgeschnitten hatten, die einigen Berichten zufolge offenbar einen SSL-2.0-Handshake (!) probierten oder vielleicht doch SSL 3.0 (ich geb das so wieder wie ich es gelesen habe, ich kann beides nicht verifizieren), jedenfalls kein TLS 1.0 oder neuer beherrschen.
Ein paar User berichteten auch von Problemen mit dem Push-Service ihres BlackBerry-Gerätes. Hier war das Debugging allerdings etwas komplizierter, denn die Fehlermeldung die unsere User erhielten lautete lediglich:
Bei der Überprüfung des E-Mail-Kontos ist ein Fehler aufgetreten. Überprüfen sie ihre Informationen, und versuchen sie es erneut.
Such message. Many obvious. Much helpful. Amaze. Wow.
(Liebe Entwickler, technisch aussagekräftige Fehlermeldungen vor den Usern zu verstecken, weil sie verwirrend sein könnten ist nicht benutzerfreundlich sondern bevormundend. Vor allem hilft es nicht bei der Fehlersuche und -behebung.)
Aus der Kommunikation mit den Usern ging hervor, dass möglicherweise auch hier SSL 3.0 das Problem sein könnte, jedenfalls wurde wohl versucht eine IMAPS-Verbindung auf Port 993 aufzubauen. Auf Port 993 wurde traditionell SSL 3.0 verwendet, da mit der Einführung von TLS 1.0 eigentlich auf Port 143 das STARTTLS-Kommando verwendet werden sollte, was aber den kleinen Nachteil hat dass die Kommunikation im Klartext beginnt und erst nach dem STARTTLS-Kommando verschlüsselt wird. Einige User zogen daher immer Port 993 vor und die von uns eingesetzte IMAP-Software Dovecot honoriert das indem sie auf diesem Port auch TLS 1.0 und neuer unterstützt (und seit wir die Konfiguration im letzten Jahr angepasst haben eben kein SSL 3.0 mehr).
Wie sich herausstellt, gibt es ein Tool mit dem die Kompatiblität eines Mail-Dienstes mit BlackBerry-Geräten getestet werden kann. Einer unserer User hat darüber herausgefunden, dass wohl auch IMAP auf Port 143 probiert wird und er hatte eine zumindest für uns einigermaßen lesbare, aussagekräftigere Fehlermeldung erhalten:
java.lang.RuntimeException: Could not generate DH keypair
Das Problem scheint hier weniger SSL 3.0 zu sein (wobei es das auch sein könnte, zusätzlich), sondern an anderer Stelle zu liegen: Unsere Server sind (selbstverständlich) so konfiguriert, dass sie Perfect Forward Secrecy (PFS) ermöglichen. Das heißt, dass Client und Server beim Aushandeln der Verschlüsselung Einmal-Schlüssel generieren die dann für die Verschlüsselung verwendet und danach gelöscht werden. Der Vorteil hieran ist, dass ein Angreifer diese Kommunikation noch nichtmal dann entschlüsseln kann, wenn er sie aufzeichnet und später den Server kompromitiert und dessen permanente Schlüssel kopiert, denn die Einmal-Schlüssel die zum Entschlüsseln auch notwendig wären sind dann nicht mehr vorhanden und können auch nicht rekonstruiert werden. Bei PFS wird ein sogenannter Diffie-Hellman-Schlüsseltausch gemacht (oft abgekürzt mit “DH”) und für diesen Schlüsseltausch werden Diffie-Hellman-Parameter gebraucht die von der Länge her zu den verwendeten Schlüsseln passen sollten.
Die obrige Fehlermeldung klingt danach, als ob hier entweder gar kein Diffie-Hellman-Schlüsseltausch unterstützt wird oder noch eher als ob der Gegenseite die Diffie-Hellman-Parameter die wir verwenden zu lang sind. (Wir verwenden 2048 Bit Diffie-Hellman-Parameter, viele ältere Programme beherrschen aber nur 1024 oder gar 512 Bit, was für zeitgemäße kryptographische Verfahren viel zu kurz ist. Eigentlich würden wir sogar schon auf 4096 Bit umstellen wollen, aber nichtmal unsere Software beherrscht das und es ist auch zu langsam, wir warten hier darauf dass endlich vertrauenswürdige Elliptische Kurven für einen Diffie-Hellman-Schlüsseltausch mit Elliptischen Kurven (ECDHE) verfügbar werden.)
Es ist übrigens möglich mit unseren Servern eine Verschlüsselung ohne PFS und dementsprechend ohne DH auszuhandeln. Unsere Server schicken jedem Client eine Liste der Verschlüsselungsverfahrenskombinationen die sie unterstützen und die ist in absteigender Priorität sortiert, in menschenlesbarer Form dargestellt sieht das in etwa so aus:
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD
AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1
AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1
Ich übersetze das mal von menschen_lesbar_ in menschen_verständlich_:
- Als erstes steht immer der Name für die gesamte Kombination von Verschlüsselungsverfahren.
- Dann folgt die Angabe in welchem Standard diese Verfahrenskombination zuerst spezifiziert wurde. (Wichtig: SSLv3 heißt hier nicht, dass SSL 3.0 verwendet wird!)
- “Kx” steht für “Key Exchange”, hier stehen bei uns die asymetrischen Verfahren DH und RSA zur Verfügung. RSA bedeutet, es wird der Schlüssel vom Zertifikat des Servers verwendet und wenn der kompromitiert wird (z.B. mit einer Attacke wie Heartbleed), dann lassen sich frühere Kommunkationsvorgänge damit entschlüsseln. Bei einem reinen DH-Verfahren wäre das auch möglich, wenn die Diffie-Hellman-Parameter kompromitiert werden, aber erstens tauschen wir die regelmäßig aus, zweitens verwenden wir nur DH-Verfahren die PFS bieten, bei diesen wird obendrein ein Einmal-Schlüssel ausgehandelt der nach dem Kommunikationsvorgang nicht aufgehoben wird.
- “Au” bezeichnet das Authentifikations-Verfahren mit dem der Client sicherstellt, ob der Server wirklich derjenige ist der er zu sein vorgibt (es geht auch in die andere Richtung mit Client-Zertifikaten, was wir aber nicht nutzen). Hier wird wiederum der Schlüssel vom Zertifikat des Servers verwendet.
- Bei “Enc” steht die am Ende verwendete symmetrische Verschlüsselungsmethode und Schlüssellänge.
- “Mac” bezeichnet das Verfahren mit dem überprüft wird ob die Pakete die Client und Server austauschen unterwegs manipuliert wurden.
Kurzfassung: Unsere Server priorisieren starke Verfahren: AES-GCM vor AES-CBC vor Camellia; 256 Bit Schlüssellängen vor 128 Bit; AEAD vor SHA256 vor SHA1 und eben Verfahren mit PFS vor Verfahren ohne PFS (alles was mit “DHE” beginnt bietet PFS).
Fazit: Derzeit ist bei BlackBerry die Push-Funktion (über BlackBerry Enterprise Service (BES) oder BlackBerry Internet Service (BIS)) mit unseren Servern inkompatibel. Die Software auf der Gegenseite könnte auf ein Verfahren ohne DH zurückfallen, wenn sie denn kein DH beherrscht oder sich an der Länge unserer DH Parameter verschluckt, tut dies aber leider nicht.
Einer unserer User war bass erstaunt darüber dass bei diesem Push-Verfahren seine Mails über einen dritten Anbieter (in diesem Fall seinen Mobilfunk-Anbieter) laufen, der auch seine Zugangsdaten zum Mail-Konto dafür im Klartext speichern muss und dass obendrein noch nichtmal zeitgemäße Verschlüsselung unterstützt wird, RIM werbe doch schließlich mit “sicherer Kommunikation” und behaupte auf dem Gebiet führend zu sein.
Dem habe ich nichts weiter hinzuzufügen, empfehle aber eine Suche mit der Suchmaschine des geringsten Misstrauens unter Verwendung von Begriffen wie RIM, BlackBerry und vielleicht Indien oder Saudi-Arabien. Aber vorsicht: Knowledge brings fear.