Wenn Lücken wie POODLE bekannt werden, herrscht bei uns schon fast soetwas wie Routine. Diejenigen von uns die sich um solche Dinge kümmern verabschieden sich von allen Plänen für den Nachmittag, den Abend, die Nacht, machen im Browser Tabs mit den üblichen IT-News-Seiten, den Homepages der von uns verwendeten Softwares und (zur zwischenzeitlichen Entspannung) mit Katzen- oder Hundecontent auf und dann heißt es Warten auf Details und Softwareupdates. Bei POODLE wurde schnell klar, dass es diesmal weniger um Updates geht, als vielmehr darum SSL 3.0 endlich abzuschalten. Das sollte bei einem 18 Jahre alten Protokoll, das bereits drei Nachfolger hat eigentlich überhaupt kein Problem sein. (Um ganz ehrlich zu sein: eigentlich ist es eine Schande, dass SSL 3.0 und TLS 1.0 nicht schon seit Jahren überall abgeschaltet werden können.) Gerade nach der BEAST-Lücke in TLS 1.0 haben viele Browser auch mit 10jähriger Verzögerung endlich angefangen neuere Standards wie TLS 1.1 oder 1.2 zu implementieren, da sollte doch einer Abschaltung von SSL 3.0 wirklich nichts mehr im Wege stehen. Oder?

Leider nicht ganz. Bei SSL/TLS ist leider immer alles anders als wir es uns in unseren schlimmsten Träumen ausmalen.

Am einfachsten wäre natürlich, genügte es OpenSSL neu zu kompilieren und dabei den Support für SSL 3.0 einfach wegzulassen, es gibt da bei OpenSSL durchaus eine Option für, die scheint aber SSL 3.0 nicht vollständig zu deaktiveren. Außerdem führt es leider in vielen Programmen die gegen OpenSSL linken zu Problemen, weil sich OpenSSL dann nicht mehr so verhält wie sie es erwarten. An der Stelle ist es müßig sich einmal mehr darüber aufzuregen wie furchtbar OpenSSL ist, es ist derzeit noch die einzige weit verbreitete Kryptographie-Bibliothek für TLS die von den meisten Softwares verwendet wird, selbst ein Drop-In-Replacement (das derzeit möglicherweise in Arbeit ist) müsste die gleiche API bereitstellen und wäre daher zwangsläufig nicht viel besser. Also Augen zu und durch.

Bei größeren bzw. weit verbreiteten Softwareprojekten wie Apache, Nginx, Lighttpd und Dovecot besteht oberflächlich erstmal kein Problem, dort gibt es meist Möglichkeiten ein Protokoll wie SSL 3.0 über die Konfiguration abzuschalten, manchmal sind sie nicht gut dokumentiert, aber es gibt hier auf der Serverseite keine allzu großen Probleme. Kniffliger wird es bei kleineren (wenn auch zum Teil weit verbereiteten) Softwareprojekten wie qmail, Spamdyke und Pound, denn dort fehlen solche Optionen häufig oder sie sind schlecht bis undokumentiert.

Als POODLE veröffentlicht wurde, setzten wir fünf Softwares ein die SSL/TLS sprachen und gegen OpenSSL linkten: Apaches mod_ssl, Pound, Dovecot, Spamdyke und qmail mit mehreren Patches (letzteres fiel dann weg, dazu später mehr).

Bei Apache war die nötige Änderung in der Konfiguration am einfachsten, aus SSLProtocol -all -SSLv2 +SSLv3 +TLSv1 wurde SSLProtocol -all -SSLv2 -SSLv3 +TLSv1 und nach einem Neustart des Dienstes war alles in Ordnung. Dummerweise setzen wir mod_ssl nur auf ein paar wenigen, älteren Hosts ein, weil es insgesamt für unser Setup zu schwerfällig und unflexibel ist. (Neustarts von Apache dauern zu lange und das Einbinden von User-Zertifikaten ist unhandlich.)

Auf neueren Hosts – auf der Mehrheit unserer Hosts – haben wir vor Apache noch einen Reverse Proxy namens Pound im Einsatz, der nach außen HTTP und HTTPS spricht und beides als HTTP an Apache durchreicht. (Damit lassen sich User-Zertifikate viel besser einbinden und wir haben sogar noch eine Rechtetrennung zwischen Pound und Apache.) Für Pound mussten wir letzten Endes erstmal selbst einen Patch schreiben, weil zunächst keiner verfügbar war der bei uns funktionierte. Glücklicherweise war das in diesem Fall nicht allzu kompliziert: nach SSL_CTX_set_options(pc->ctx, SSL_OP_NO_SSLv2); wurde einfach noch ein SSL_CTX_set_options(pc->ctx, SSL_OP_NO_SSLv3); ergänzt. – Nicht der hübscheste Patch, aber wer hat schon Zeit (und Lust) in einer archaischen und alle Kritik verdienenden Programmiersprache wie C noch eine Config-Option für etwas einzubauen, das ohnehin nie wieder angeschaltet werden soll.

Alles in Allem waren wir was das WWW angeht nach wenigen Stunden mit dem Abschalten von SSL 3.0 fertig und es gab erfreulicherweise keine Meldungen von Usern, dass sie Webseiten nicht mehr erreichen können (wohl auch deswegen, weil wir schon seit Ende April 2014 keine von den Museums-Ciphern mehr unterstützen die WindowsXP braucht, dessen letzte verbliebene, sehr mutige User konnten unsere Webseiten schon länger nicht mehr per HTTPS erreichen). Leider nutzt aber nicht nur HTTPS SSL/TLS…

IMAP4 und POP3 wickeln wir mit Dovecot ab und hier war die Situation bereits etwas komplizierter. Wir setzten da noch eine Version aus dem 2.0-Zweig von Dovecot ein, weil bei Version 2.1 neue IMAP-Namensraum-Magie dazu kommt und IMAP-Clients auf solche Änderungen erfahrungsgemäß nicht gut reagieren, selbst wenn die serverseitige Konfiguration extra gegensteuert. In Dovecot 2.0 ließ sich SSL 3.0 aber leider nicht so einfach abschalten, also blieb uns hier nur die Flucht nach vorn. Das Update auf ein aktuelles Dovecot 2.2 war schon länger geplant und in Vorbereitung, jetzt mussten wir es also durchziehen. Immerhin beherrscht Dovecot 2.2 auch halbwegs zeitgemäßes DHE (Ephemeral Diffie Hellman Key Exchange) und bietet damit PFS (Perfect Forward Secrecy), einer der Gründe warum wir das schon länger einführen wollten. (Dovecot 2.0 beherrschte schrecklicherweise nur DHE mit 512 und 1024 Byte langen Parametern, was heutzutage viel zu kurz ist, Dovecot 2.2 beherrscht immerhin DHE mit 2048 Bit langen Parametern, auch wenn mittlerweile schon 4096 Byte Länge wünschenswert wären. Dovecot ist da aber nicht allein, praktisch keine der von uns eingesetzten Softwares beherrscht schon 4096 Byte lange DH Parameter.)

Bei SMTP war die Sache komplizierter: Auf unseren älteren Servern kommunizierte qmail noch selbst per SMTP, SMTPS oder SMTP+STARTTLS, während auf allen neueren Servern ähnlich wie bei Apache und Pound ein weiterer Dienst namens Spamdyke vor qmail sitzt und die TLS-Verschlüsselung abwickelt. Wir setzen Spamdyke ein um einen Teil des auf unsere Mail-Server permanent einprasselnden Spams mit DNS-basierten Blacklisten abzuwehren, außerdem ist die TLS-Konfiguration bei Spamdyke etwas handlicher als bei qmail mit TLS-Patch.

Um die Sache noch etwas komplizierter zu machen hatte unser SMTP-Setup auf den älteren Hosts mit CentOS 5 einen Bug der es erlaubte, dass auch auf den Ports 25 und 465 Mails zum Relaying abgegeben werden konnten, solange der Client sich vorher authentifiziert. Auf allen neueren Hosts mit CentOS 6 war das nicht möglich, hier mussten Mails zum Relaying schon immer auf Port 587 abgeliefert werden. Einen etwas hinkenden Vergleich bietet hier der gute alte Briefkasten: davon gibt es auch zwei Sorten, die eine ist meist groß, gelb, oft an Kreuzungen anzutreffen und darin werden Briefe eingeworfen damit die Post sie zustellt (Relaying), die andere ist meist kleiner, nicht farbgebunden, an Häusern anzutreffen und darin werden Briefe von Boten zur Endzustellung eingeworfen.

Auch hier hatten wir eine Umstellung der älteren Server auf das neue Spamdyke-Setup schon länger geplant, für die neueren Server stand außerdem ein Spamdyke-Update an (erst die jüngste Spamdyke-Version aus diesem Sommer beherrscht überhaupt DHE und damit PFS, wir wollten diesen letzten Mangel an PFS-Support schon länger beheben, zum Glück waren die Vorbereitungen auch schon fast fertig).

Das große Problem war nun: Anders als bei Browsern von denen es nicht so viele gibt und die immer wenn es um TLS geht auch ins Licht der Aufmerksamkeit rücken, gibt es was IMAP4/POP3/SMTP angeht sehr viele Clients (bei SMTP kommen noch viele andere Mail-Transfer-Agents als Clients hinzu) und nicht nur wird diesen viel weniger Beachtung geschenkt wenn es um TLS geht, sondern gerade bei SMTP muss zwangsläufig damit gerechnet werden, dass es in den finsteren Ecken des Internets noch eine erschreckende Menge sehr veralteter Mail-Transfer-Agents gibt. Zusammen mit dem oben erwähnten, alten Bug in unserem SMTP-Setup mussten wir also mit einer größeren Anzahl von Supportanfragen rechnen, zumal einige von uns (zurecht wie sich herausstellte) befürchteten, dass einige Mail-Clients ohne SSL 3.0 abgeschnitten werden. Wir haben daher die Umstellung auf das neue Setup über drei Wochen verteilt und wann immer Zeit war nur eine Handvoll Server umgestellt.

Erfreulicherweise gab es weniger Supportanfragen als befürchtet, das meiste waren eher harmlose Fälle:

• Die meisten anfragenden User waren tatsächlich in den alten Bug in unserem Setup gelaufen und mit einer Umstellung ihres Mail-Clients von Port 25 oder Port 465 auf Port 587 war ihnen geholfen. Die Unannehmlichkeiten tun uns an der Stelle leid, aber letztlich hätte das von Anfang an nicht funktionieren sollen und in unserer Dokumentation stand auch immer schon “nehmt Port 587” – insofern waren das im Grunde aufgeschobene Supportanfragen, die uns eigentlich schon bei der ersten Einrichtung des Mail-Clients hätten erreichen müssen. So oder so: Ein leicht und schnell zu behebendes Problem.
• Einige User hatten in ihren Mailclients absichtlich SSL 3.0 und nicht TLS 1.0/1.1/1.2 eingestellt, weil sie irrigerweise annahmen, SSL 3.0 müsste wegen der 3.0 im Namen ja neuer und besser sein. Hier lässt sich gegen die User kein Vorwurf erheben, denn es ist schlicht und ergreifend ein alter Skandal, dass dieses offensichtliche Problem bei der ersten Version von TLS nicht antizipiert und vermieden wurde. Hätte es irgendjemandem einen Zacken aus der Krone gebrochen das Protokoll TLS 4.0 zu taufen? (Vor Kurzem wurde viel Häme über Microsoft ausgeschüttet, weil sie aus ähnlichen Gründen die Versionsnummer “Windows 9” auslassen werden. Natürlich möchte man sich bei soetwas an den Kopf fassen – aber in der Sache tut Microsoft hier das einzig richtige und umgeht vermeidbare Fehler.)
• Ein paar User hatten das ältere SSL 3.0 dem neueren TLS vorgezogen weil dann grundsätzlich die Verbindung mit einem SSL-Handshake beginnen muss und erst danach überhaupt IMAP4/POP3/SMTP mit dem Server gesprochen wird. Bei TLS ist es umgekehrt: der Client verbindet sich in einer Klartextverbindung mit dem Server und spricht den Server per IMAP4/POP3/SMTP an, erst wenn der Server daraufhin mitteilt dass er das STARTTLS-Kommando versteht, kann der Client einen TLS-Handshake einleiten. Es gibt durchaus Konstellationen in denen der Client den TLS-Handshake nicht macht oder wenn dieser missslingt einfach im Klartext weitermacht und dann Usernamen und Passwörter für alle Welt lesbar durchs Internet posaunt. Das ist ein grundsätzliches Problem mit STARTTLS. Deswegen haben auch einige von uns in ihren Mail-Clients bis vor einiger Zeit SSL 3.0 bevorzugt. (Immerhin: bei IMAP4 und POP3 gibt es einen Weg dies zu vermeiden: diese Protokolle hatten für Clients die mit einem SSL-Handshake beginnen wollen/sollen stets einen extra Port über den das auch weiterhin möglich ist. Unsere Umstellung hat auf diesem Port nun zwar SSL 3.0 deaktiviert, aber dort kann durchaus ein TLS-Handshake gemacht werden und STARTTLS somit weiterhin vermieden werden. Erfreulicherweise kommen einige Mail-Clients damit klar. Bei SMTP gibt es diese Möglichkeit leider nicht, bzw. es gibt sie über Port 465 nur für die Kommunikation zwischen Mailservern untereinander, aber leider nicht für die Kommunkation zwischen Mail-Client und -Server.)
• Natürlich gab es wie befürchtet auch ein paar Berichte von Mail-Clients die schlicht kein SSL 3.0 beherrschen, größtenteils handelte es sich dabei um ältere Versionen oder Software die nicht mehr weiterentwickelt wird.
• Und wie befürchtet beobachten wir einige Mail-Server die mit unseren Servern nun keine Verschlüsselung mehr aushandeln können (Das Problem mit derart ranzigen Mail-Servern gibt es schon viel länger, deswegen erlauben wir für die Server-to-Server-Kommunkation bei SMTP als letzten Ausweg auch nach wie vor die eigentlich gebrochenen Cipher RC4 und 3DES.)
• Ebenfalls ärgerlich waren ein paar Fälle in denen wie befürchtet IMAP4-Clients nach dem Dovecot-Update mit den Namensräumen völlig durcheinander kamen. In einem Fall war es unsere Schuld durch einen Fehler im Setup, ansonsten war es einfach ein ärgerlicher Nebeneffekt. Das betreffende Mail-Konto aus dem Client zu löschen und neu einzurichten hat in allen Fällen geholfen.

Aber bei TLS kommt ja nie etwas weniger schlimm als befürchtet, sondern eher viel schlimmer – so auch diesmal:

• Von ein paar Usern erfuhren wir, dass ihr aktueller Mail-Client, von dem es keine aktuellere Version für ihre Plattform gibt und für den sie sogar gutes Geld bezahlt haben tatsächlich nicht in der Lage ist einen TLS-Handshake auszuführen, sondern höchstens nach einem SSL-Handshake TLS einleiten kann, was natürlich wenn POODLE vermieden werden soll sinnlos ist. m(

Damit ist die Umstellung nun endlich abgeschlossen und wir verabschieden uns endgültig von SSL 3.0 und der ungeliebten Doppeldeutigkeit von SSL/TLS, von nun an heißt es nur noch TLS.

(Und wir bereiten uns auf das Worst-Case-Szenario vor, in dem TLS 1.0 gebrochen wird bevor nahezu alle Programme wenigstens TLS 1.1 beherrschen (aktueller Stand: Gerüchten zufolge fast 50%): Wir kaufen Vorräte und One-Way-Flugtickets in die Karibik.)

• ← Previous Post
• Next Post →