SSLv3: Uralt, bröckelig, abschalten!
[EDIT] Tja, da schreibt man gerade drüber und ein paar Minuten später wird die Lücke veröffentlicht: Poodle . Details im Google Blog. Das Problem liegt im SSLv3 Protokoll selbst, es wird keine Patches geben, es muss ausgeschaltet werden. Eigentlich wäre nur uralt-Software wie der IE6 unter WindowsXP betroffen, aber durch Downgrade-Attacken die bei TLS möglich sind, sind alle betroffen und können auf das schwache SSLv3 downgegraded werden wenn es denn auf Server+Client unterstützt wird. Also abschalten!
Seit 2 Tagen gibt es Gerüchte über eine kritische Lücke in SSLv3. Aktuell (Mitternacht) ist noch nichts publik geworden außer ein eventuell interessanter Patch von Microsoft, und eine Falschmeldung eines OpenBSD-Patches, der in Wirklichkeit schon einige Monate alt ist.
Sicher ist dass SSLv3 18 Jahr alt ist, und vor 15 Jahren durch TLSv1.0 abgelöst wurde. Bei mail.de haben wir SSLv3 bereits vor einigen Monaten deaktiviert auf den Webseiten da kaum ein Client dieses alte Protokoll benutzte außer der IE6 auf WindowsXP Systemen. Da wir den IE6 eh schon lange nicht mehr unterstützen war es sehr einfach, SSLv3 abzuschalten.
Für die anderen Protokolle wie IMAP, POP3 und SMTP haben wir SSLv3 allerdings noch aktiviert gelassen da es noch diverse E-Mail-Clients gibt die TLS >1.0 noch nicht beherrschen. Auch einige ältere Smartphones beherrschen noch kein TLS1.0 oder neuer, sodass es Sinn machte es noch aktiviert zu lassen, denn es gab auch (noch) keine bekannten Angriffsvektoren.
Da nun aber die Gerüchteküche kocht und es dort wirklich etwas zu geben scheint, haben wir es kurzerhand nun deaktiviert, um der Veröffentlichung zuvorzukommen. Da es pro Tag nur knapp 20 Verbindungen gab die noch SSLv3 genutzt haben sind so wenige Kunden betroffen dass wir es verantworten können.
Auch ihr solltet darüber nachdenken SSLv3 abzuschalten, allem voraus in euren Webservern.
SSLv3 in nginx deaktivieren
Ich empfehle für nginx aktuell die folgenden SSL-Einstellungen:
ssl_protocols TLSv1.1 TLSv1.2 TLSv1; ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:RSA+3DES:!ADH:!AECDH:!MD5; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m;
SSLv3 im Apache deaktivieren
Für den Apache müsste es folgende Einstellung sein wenn ich das richtig sehe. Habe leider keinen Apache mit SSL parat zum testen:
# apache bis 2.2.22 SSLProtocol all -SSLv2 -SSLv3 # apache ab 2.2.23 SSLProtocol TLSv1 TLSv1.1 TLSv1.2
SSLv3 in Dovecot deaktivieren
Seit Version 2.1 lässt sich SSLv3 so deaktivieren:
ssl_protocols = !SSLv2 !SSLv3
Ältere Versionen muss man manuell patchen, aber hoffentlich verwendet keiner von euch mehr so alte Versionen.
SSLv3 in Postfix deaktivieren
smtpd_tls_protocols = !SSLv2, !SSLv3 smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 smtp_tls_protocols = !SSLv2, !SSLv3
SSLv3 in HAProxy deaktivieren:
bind :443 ssl crt <crt> ciphers <ciphers> no-sslv3
SSLv3 in Firefox deaktivieren:
Einfach in der Adressleiste about:config eintippen, dann nach „tls“ suchen und die Option security.tls.version.min auf 1 stellen.
SSLv3 in Chrome deaktivieren:
In Chrome ist es ein bisschen aufwändiger, da man den Browser mit der Kommandozeilen-Option –ssl-version-min=tls1 starten muss. Am einfachsten legt man sich einen entsprechenden Shortcut an.
SSLv3 im Internet Explorer deaktivieren:
Im Internet Explorer kann man in den Internetoptionen unter Erweitert SSL 3.0 verwenden abwählen – und bei der Gelegenheit auch gleich TLS 1.1 und 1.2 aktivieren.
Wie teste ich ob SSLv3 unterstützt wird?
Webseiten kann man am einfachsten mit dem Qualys SSL-Tester online prüfen:
https://www.ssllabs.com/ssltest/index.html
So prüft man ob seine Dienste noch SSLv3 unterstützen:
openssl s_client -crlf -ssl3 -connect imap.mail.de:993 openssl s_client -starttls smtp -crlf -ssl3 -connect mx01.mail.de:25 openssl s_client -starttls smtp -crlf -ssl3 -connect smtp.mail.de:587 openssl s_client -ssl3 -connect mail.de:443
Natürlich muss dort der passende Hostname des zu testenden Servers eingegeben werden.
Wenn SSLv3 nicht unterstützt wird, dann wird die folgende Fehlermeldung angezeigt und die Verbindung kommt nicht zustande:
New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported
Kommt eine Verbindung zustande sieht man folgende Informationen:
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol: SSLv3
Danke – exakt so eine Zusammenfassung habe ich gesucht. Selbst Fachzeitschriften ergehen sich in langen Berichten, ohne einen einzigen konkreten Hinweis … dein Post hilft weiter!
Shardan
15 Okt 14 at 13:12
Hi,
Maßnahmen heute umgesetzt, scheint so weit zu klappen. Zufällig in nem komplett anderen Kontext nen cURL Aufruf via Guzzle auf die Seite gemacht und folgende Antwort erhalten:
60: SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Arbeitet cURL wirklich default mit SSLv3? Und wenn ja, wie kann ich das verhindern?
Michael
15 Okt 14 at 14:00
@Michael: „certificate verify failed“ hört sich eher nach einem Zertifikatsfehler an. Hast du curl evtl. nicht gesagt wo es die Root-Zertifikate findet? CApath oder wie der Parameter heißt? Oder handelt es sich um ein selbstsigniertes oder abgelaufenenes Zertifikat?
Wenn du mit curl versuchst eine SSLv3 Verbindung aufzubauen die der Server nicht unterstützt müsste die Fehlermeldung glaube ich „error:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure errno:35“ lauten…
Michael Kliewe
15 Okt 14 at 14:54
Danke, dein Artikel hat mir sehr geholfen!
Patrick
15 Okt 14 at 15:13
Ich hab es schon seit Monaten deaktiviert direkt nachdem Cherokee (nach Request) eine Option dafür eingefügt hatte. Beschwerden gab es deshalb bis heute nicht. Bei Mail brauche ich es nicht, weil ich sowieso SSLv3 in Thunderbird deaktiviert habe. Bei neuen Server sperre ich es aber. 🙂
Oliver
16 Okt 14 at 09:45
Es funktioniert, Dank für den Artikel
Ardekay
19 Jan 15 at 11:41