POODLE: SSLv3 via HTTPS deaktiviert
Schon den ganzen Tag gerüchtete es, dass im Laufe des 15. Oktober nach Heartbleed und Shellshock eine weitere Sicherheitslücke mit großem, Internet-weiten Ausmaß angekündigt wird. Inzwischen sind die Details dazu publik.
Wie bei vergangenen SSL-/TLS-bezogenen Angriffen (CRIME, BEAST, etc) hat dieser Angriffsvektor mit POODLE (Padding Oracle On Downgraded Legacy
Encryption) von Google ein durchaus aussprechbares und einprägsames Akronym als Namen erhalten - auch wenn POODLE sowohl ohne dedizierte Webseite als auch ohne ein dramatisches Logo auskommen musste.
Der Angriff
SSLv3 war uns schon länger ein Dorn im Auge. Letztendlich ist SSLv3 nicht nur ein altes, sondern vor allem ein überholtes und unsicheres Protokoll, weil es keinen der heute (noch) als kryptograpisch sicher geltenden Cipher beherrscht.
Da auch moderne Browser leider weiterhin einen Fallback-Mechanismus auf SSLv3 beherrschen, ließen sich theoretisch sichere Verbindungen mit TLSv1.1+ durch Störung des Traffics eines Clients dazu überreden, stattdessen die vermeintlich sichere Verbindung per SSLv3 aufzubauen. Durch POODLE sind diese Verbindungen aber anfällig für Angriffe auf die zugrunde liegende Verschlüsselung, so dass die übertragenen Daten von einem Angreifer verhältnismäßig trivial entschlüsselt werden können. Derzeit basiert dieser Angriff darauf, dass durch eine Vielzahl automatisierter HTTP-Zugriffe die Blockgröße des Cookies zu bestimmen und anhand dessen durch Schwächen des CBC-Ciphers an den Klartext zu gelangen. Weitere technische Details dazu finden sich im Paper zu POODLE.
Die SSLv3-Problematik
Bisher gab es schlichtweg keine ausreichend großen Setups, die SSLv3 gänzlich deaktivieren, so dass schlichtweg nicht abzusehen war, welche Konsequenzen das für die Client-Kompatibilität hat. Gänzlich bekannt sind diese nicht. Google schlägt vor, in Fällen in denen SSLv3 aus Kompatibilitätsgründen nicht sofort deaktiviert werden kann, stattdessen TLS_FALLBACK_SCSV zu implementieren.
Wer Chrome nutzt und viel mit Google-Servern kommuniziert, der hat seit mehreren Monaten eben jenen Flicken für den SSLv3-Fallback mitgetestet. Googles Plan sieht allerdings vor, SSLv3 in den nächsten Wochen vollständig zu deaktivieren, sofern keine erheblichen Probleme auffallen.
Auch Cloudflare verkündet, SSLv3 seit heute standardmäßig deaktiviert zu haben.
Da wir von einer nahezu nicht vorhandenen Anzahl von SSLv3-Verbindungen ausgehen, haben wir uns ebenfalls dazu entschlossen, bereits heute sämtliche Unterstützung für SSLv3 zu deaktivieren. Wir befinden uns mit unserer Entscheidung also in guter Gesellschaft.
Pound-Patch
Wir nutzen für unser SSL-Setup inzwischen größtenteils Pound als SSL-Proxy, mit wenigen Hosts als Ausnahme, die noch aus unseren Anfangszeiten stammen, die noch mit mod_ssl laufen. Für Pound gibt es keine triviale Möglichkeit, SSLv3 über die Konfigurationsdatei zu deaktivieren. Insofern haben wir uns damit beholfen, einen kleinen Patch für Pound zu schreiben, der die SSLv3-Unterstützung deaktiviert. Daraufhin haben wir die gepatchte Pound-Version auf unseren Entwicklungs-Hosts getestet und sie nach erfolgreichen Tests auf sämtliche Uberspace-Hosts verteilt und die laufenden Pound-Instanzen neugestartet.
mod_ssl
Einige unserer ersten Uberspace-Hosts laufen derzeit noch dem Apache-Modul mod_ssl. Im Apache lässt sich SSLv3 glücklicherweise einfacher deaktivieren:
SSLProtocol -all -SSLv2 -SSLv3 +TLSv1
Danach reichte ein Neustart des Apache.
Mail (IMAP, POP3, SMTP)
Derzeit basiert der Angriff auf HTTPS. Inwieweit sich POODLE auch auf Mail-Protokolle anwenden lässt, ist noch unbekannt. Da Mailclients bei ihrer TLS-Unterstützung oftmals etwas hinterher hinken, kann es schwierig werden, SSLv3 gänzlich zu deaktivieren. Wir werden das in den kommenden Tagen aber testen und unser Mail-Setup dahingehend optimieren.