So, die Änderungen sind alle eingecheckt und werden nun von unserem Jenkins compiliert & getestet (das dauert noch eine Weile...). Sobald die Pakete fertig sind gebe ich noch mal Bescheid.
Die geänderten Einstellungen sind:
- Apache:
[highlight]SSLProtocol ALL -SSLv2 -SSLv3[/highlight] - nginx:
[highlight]ssl_protocols TLSv1;[/highlight] (bzw. [highlight]ssl_protocols TLSv1 TLSv1.1 TLSv1.2;[/highlight] mit nginx 1.1.13+ und 1.0.12+) - Postfix:
[highlight]smtpd_tls_protocols = !SSLv2, !SSLv3[/highlight] (Postfix v2.6+)
[highlight]smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3[/highlight] (Postfix v2.5)
[highlight]smtpd_tls_mandatory_protocols = TLSv1[/highlight] (Postfix <v2.5) - Dovecot:
Dovecot 1.x: SSLv3 kann nicht abgeschaltet werden (s.u.)
Dovecot ab 2.1: [highlight]ssl_protocols = !SSLv2 !SSLv3[/highlight] - ProFTPd:
[highlight]TLSProtocol TLSv1[/highlight] - vsftpd:
keine Änderung notwendig, SSLv3 war bereits deaktiviert (ssl_sslv3=NO)
Bei Dovecot 1.x/2.0 lässt sich SSLv3 nicht abschalten (zumindest nicht ohne den Code zu patchen). Das ist aber auch nicht dramatisch, da die POODLE-Attacke voraussetzt, dass der Angreifer die Daten beeinflussen kann, die zum Server gesendet werden - wie auch bei den BEAST- und CRIME-Angriffen. Das klappt in der Praxis nur dann mit realistischem Aufwand, wenn man in eine Webseite JavaScript-Code einschleust und den Datenverkehr komplett abhören kann (z.B. mit WLAN-Proxies). Da bei POP3/IMAP-Zugriffen praktisch kein Einfluss auf die vom Client zum Server gesendeten Daten genommen werden kann, ist ein Angriff dort (nach derzeitigem Wissensstand) praktisch nicht möglich.
Insgesamt ist der POODLE-Angriff ernst zu nehmen, aber nicht annähernd so schlimm wie Heartbleed oder Shellshock. Es handelt sich um einen Angriff auf den Client (konkret: auf den Webbrowser), der auch nur dann möglich ist, wenn man die komplette Kommunikation zwischen Client und Server "abhören" kann (insbes. also bei WLANs).
