Hintergrundinformation
SSL soll das Transportniveau im Internet sichern. Für "das Web" oder "HTTP" wird dies als HTTPS bezeichnet, es wird jedoch auch für andere Anwendungsprotokolle verwendet. SSLv2 war das erste weit verbreitete Transportsicherheitsprotokoll, wurde jedoch nicht lange danach als unsicher eingestuft. Die Nachfolger SSLv3 und TLSv1 werden jetzt weitgehend unterstützt. TLSv1.1 und TLSv1.2 sind neuer und gewinnen auch viel Unterstützung. Die meisten, wenn nicht alle ab 2014 veröffentlichten Webbrowser unterstützen dies.
Die jüngste Entdeckung von Google-Ingenieuren zeigt, dass SSLv3 nicht mehr verwendet werden sollte (wie SSLv2 vor langer Zeit veraltet ist). Die Clients, die keine Verbindung zu Ihrer Site / Ihrem Service herstellen können, sind wahrscheinlich sehr, sehr begrenzt. CloudFlare gab bekannt, dass weniger als 0,09% seiner Besucher immer noch auf SSLv3 setzen.
Einfache Lösung: SSLv3 deaktivieren.
Bietet Ubuntu ein Update?
Ja, über usn-2385-1 mit der Hinzufügung der SCSV-Funktion, aber das Problem wird dadurch nicht vollständig behoben , da SSLv3 nicht deaktiviert wird und der Patch nur funktioniert, wenn beide Seiten der Verbindung gepatcht wurden. Sie erhalten es durch Ihre regelmäßigen Sicherheitsupdates in Ihrem Paketmanager.
Also, noch SIE haben , Maßnahmen zu ergreifen , um sich SSLv3 zu deaktivieren (es ist konfigurierbar). Zukünftige Versionen von Clients / Browsern werden SSLv3 höchstwahrscheinlich deaktivieren. Beispielsweise wird Firefox 34 dies tun.
Das vollständige Deaktivieren von SSLv3 in Ubuntu auf Implementierungsebene wird wahrscheinlich einige Dinge auch für Nicht-HTTPS-SSL-Nutzung auf den Markt bringen, die nicht so anfällig sind, daher gehe ich davon aus, dass die Betreuer dies nicht tun und nur dieser SCSV-Patch angewendet wird.
Warum behebt das SCSV-Update in OpenSSL über usn-2385-1 das Problem nicht?
Hören Sie auf, solche Fragen zu stellen, und überspringen Sie ein paar Absätze, und deaktivieren Sie SSLv3. Aber hey, wenn Sie nicht überzeugt sind, hier gehen Sie:
POODLE zeigt, dass SSLv3 mit CBC-Chiffren fehlerhaft ist. Die Implementierung von SCSV ändert dies nicht. SCSV stellt nur sicher, dass Sie kein Downgrade von einem TLS-Protokoll auf ein niedrigeres TLS / SSL-Protokoll durchführen, wie dies für die in den üblichen Fällen erforderlichen Man-in-the-Middle-Angriffe erforderlich ist.
Wenn Sie auf einen Server zugreifen müssen, der überhaupt kein TLS, sondern nur SSLv3 bietet, hat Ihr Browser keine wirkliche Wahl und muss über SSLv3 mit dem Server kommunizieren, der dann ohne Downgrade-Angriff verwundbar ist.
Wenn Sie auf einen Server zugreifen müssen, der auch TLSv1 + und SSLv3 bietet (was nicht empfohlen wird) und Sie sicherstellen möchten, dass Ihre Verbindung nicht von einem Angreifer auf SSLv3 heruntergestuft wird, benötigen sowohl der Server als auch der Client diesen SCSV-Patch.
Um das Problem vollständig zu entschärfen, reicht die Deaktivierung von SSLv3 aus, und Sie können sicher sein, dass Sie nicht herabgestuft werden. Außerdem können Sie nicht mit Nur-SSLv3-Servern kommunizieren.
Okay, wie deaktiviere ich SSLv3?
Siehe unten in den anwendungsspezifischen Abschnitten: Firefox, Chrome, Apache, Nginx und Postfix werden vorerst behandelt.
Sind nur Server oder auch Clients betroffen?
Die Sicherheitsanfälligkeit liegt vor, wenn sowohl der Server als auch der Client SSLv3 akzeptieren (auch wenn beide aufgrund eines Downgrade-Angriffs TLSv1 / TLSv1.1 / TLS1.2 unterstützen).
Als Serveradministrator sollten Sie SSLv3 jetzt zur Sicherheit Ihrer Benutzer deaktivieren .
Als Benutzer sollten Sie SSLv3 jetzt in Ihrem Browser deaktivieren , um sich beim Besuch von Websites, die SSLv3 weiterhin unterstützen, abzusichern.
Ist das OpenSSL / GnuTLS / browser spezifisch?
Nein, es ist ein Protokoll- (Design-) Fehler, kein Implementierungsfehler. Dies bedeutet, dass Sie es nicht wirklich patchen können (es sei denn, Sie ändern das Design des alten SSLv3).
Und ja, es gibt eine neue OpenSSL-Sicherheitsversion , aber lesen Sie weiter unten ( Aber ich brauche wirklich wirklich SSLv3-Unterstützung ... aus den Gründen X, Y, Z! ), Warum Sie sich besser darauf konzentrieren sollten, SSLv3 insgesamt zu deaktivieren.
Kann ich SSLv3 auf Netzwerkebene (Firewall) beenden?
Na ja, wahrscheinlich. Ich habe dies in einem separaten Blog-Post für weitere Überlegungen und Arbeiten eingestellt. Möglicherweise haben wir eine magische iptablesRegel, die Sie anwenden können!
Mein Blogeintrag: Wie kann ich mit iptables for POODLE SSLv3 in meinem Netzwerk deaktivieren?
Ist es nur für HTTPS relevant oder auch für IMAP / SMTP / OpenVPN und andere Protokolle mit SSL-Unterstützung?
Der von den Forschern gezeigte aktuelle Angriffsvektor steuert den an den Server gesendeten Klartext mithilfe von Javascript, das auf dem Computer des Opfers ausgeführt wird. Dieser Vektor gilt nicht für Nicht-HTTPS-Szenarien ohne Verwendung eines Browsers.
Normalerweise erlaubt ein SSL-Client auch nicht, dass die Sitzung auf SSLv3 heruntergestuft wird (TLSv1 + wird in den Handshake-Funktionen angezeigt), aber Browser möchten sehr abwärtskompatibel sein, und das tun sie auch. Die Kombination mit der Steuerung von Klartext und der spezifischen Art und Weise, wie ein HTTP-Header aufgebaut wird, macht ihn ausnutzbar.
Fazit: Deaktivieren Sie SSLv3 jetzt für HTTPS und SSLv3 für andere Dienste in Ihrem nächsten Dienstfenster.
Was ist die Auswirkung? Muss ich mein Serverzertifikat widerrufen und neu generieren? (Wie bei Heartbleed)
Nein, dafür müssen Sie Ihre Zertifikate nicht rotieren. Die Sicherheitsanfälligkeit stellt die Wiederherstellung von Klartext aus den Sitzungsdaten offen und bietet keinen Zugriff auf Geheimnisse (weder den Sitzungsschlüssel noch den Zertifikatsschlüssel).
Ein Angreifer ist höchstwahrscheinlich nur in der Lage, die Klartext-Header wie Sitzungscookies zu stehlen, um eine Sitzungsentführung durchzuführen . Eine zusätzliche Einschränkung ist die Notwendigkeit eines vollständigen (aktiven) MitM-Angriffs .
Kann ich sonst noch etwas tun, um meine SSL-Konfiguration im Allgemeinen zu verbessern?
Als Benutzer, abgesehen von der Deaktivierung von SSLv3 in Ihrem Browser, nicht wirklich. Installieren Sie einfach immer die neuesten Sicherheitsupdates.
Befolgen Sie für Server das TLS-Serverhandbuch von Mozilla . Und testen Sie mit dem SSL Labs-Test von Qualys . Es ist wirklich nicht so schwer, eine A + Bewertung auf Ihrer Website zu bekommen. Aktualisieren Sie einfach Ihre Pakete und implementieren Sie die Empfehlungen aus dem Mozilla-Handbuch.
Aber ich brauche wirklich wirklich SSLv3-Unterstützung ... aus den Gründen X, Y, Z! Was jetzt?
Nun, es gibt einen Patch namens SSLv3 Fallback Protection, der den Downgrade-Angriff von TLSv1-fähigen Clients umgeht. Es wird übrigens auch die Sicherheit von TLSv1 + verbessern (Downgrade-Attacke ist schwerer / unmöglich). Es wird als Backport von einer neueren OpenSSL-Version in der Ubuntu-Sicherheitsempfehlung usn-2385-1 angeboten .
Großer Haken: Sowohl Clients als auch Server benötigen diesen Patch, um zu funktionieren. Wenn Sie also sowohl Clients als auch Server aktualisieren, sollten Sie meiner Meinung nach sowieso nur auf TLSv1 + aktualisieren.
Bitte, bitte, schalten Sie SSLv3 vorerst in Ihrem Netzwerk aus. Versuchen Sie, die Sicherheitsstandards zu verbessern, und lassen Sie SSLv3 hinter sich.
Ich habe von der SCSV-Unterstützung gehört, um den Protokoll-Downgrade-Angriff zu beseitigen. Brauche ich es
Nur wenn Sie aus irgendeinem Grund wirklich SSLv3 benötigen, dies jedoch auch die Sicherheit in TLSv1 + verbessert. Daher würde ich Ihnen empfehlen, SSLv3 zu installieren. Ubuntu bietet ein Update für diese Funktion in USN-2385-1 . Sie erhalten es durch Ihre regelmäßigen Sicherheitsupdates in Ihrem Paketmanager.
Testen der Sicherheitslücke für privat gehostete Websites (z. B. Intranet / Offline).
Ihre Server sind einfach dann anfällig, wenn sie SSLv3 unterstützen. Mehrere Optionen hier:
Mit OpenSSL s_client:
openssl s_client -connect <server>:<port> -ssl3
Wenn die Verbindung erfolgreich ist, wird sslv3 aktiviert. Wenn es fehlschlägt, ist es deaktiviert. Wenn es fehlschlägt, sollten Sie etwas sehen wie:
error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
Verwenden von nmap:
nmap --script ssl-enum-ciphers -p 443 myhostname.tld
Es sollte ' SSLv3: No supported ciphers found' ausgeben . Passen Sie Ihren Hostnamen / Port an.
Verwenden von Cipherscan . Klonen / Laden Sie die Binärdatei herunter und führen Sie sie aus:
./cipherscan myhostname.tld
Es sollte nicht alles mit SSLv3 Liste unter der Spalte ‚Protokolle‘.
Firefox-Browser
Öffnen about:config, suchen security.tls.version.minund setzen Sie den Wert auf 1. Starten Sie dann Ihren Browser neu, um alle offenen SSL-Verbindungen zu löschen.
Firefox ab Version 34 deaktiviert SSLv3 standardmäßig und erfordert daher keine Aktion ( Quelle ). Zum jetzigen Zeitpunkt sind jedoch 33 veröffentlicht und 34 für den 25. November angesetzt.
Google Chrome (Linux)
Bearbeiten Sie die /usr/share/applications/google-chrome.desktopDatei, z
sudo nano /usr/share/applications/google-chrome.desktop
Bearbeiten Sie alle Zeilen, die mit Exec=include beginnen --ssl-version-min=tls1.
ZB eine Linie wie
Exec=/usr/bin/google-chrome-stable %U
wird
Exec=/usr/bin/google-chrome-stable --ssl-version-min=tls1 %U
Stellen Sie dann sicher, dass Sie den Browser vollständig schließen (Chrome-Apps lassen Ihren Browser möglicherweise im Hintergrund aktiv!).
Hinweis: Möglicherweise müssen Sie dieses Update bei jedem Update des Google Chrome-Pakets wiederholen und dabei die Startdatei überschreiben .desktop. Ein Google Chrome- oder Chromium-Browser mit standardmäßig deaktiviertem SSLv3 ist zum Zeitpunkt des Schreibens noch nicht angekündigt.
Apache HTTPD Server
Wenn Sie einen Apache-Webserver ausführen, der derzeit SSLv3 zulässt, müssen Sie die Apache-Konfiguration bearbeiten. Auf Debian- und Ubuntu-Systemen lautet die Datei /etc/apache2/mods-available/ssl.conf . Unter CentOS und Fedora lautet die Datei /etc/httpd/conf.d/ssl.conf . Sie müssen Ihrer Apache-Konfiguration die folgende Zeile mit anderen SSL-Anweisungen hinzufügen.
SSLProtocol All -SSLv2 -SSLv3
Dadurch werden alle Protokolle außer SSLv2 und SSLv3 zugelassen.
Wenn Sie schon dabei sind, können Sie die Konfiguration der Chiffresuite für Ihren Webserver verbessern, wie im TLS-Serverhandbuch von Mozilla beschrieben . Zum Beispiel hinzufügen:
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLHonorCipherOrder on
SSLCompression off
# Read up on HSTS before you enable it (recommended)
# Header add Strict-Transport-Security "max-age=15768000"
Überprüfen Sie anschließend, ob die neue Konfiguration korrekt ist (keine Tippfehler usw.):
sudo apache2ctl configtest
Starten Sie den Server neu, z
sudo service apache2 restart
Auf CentOS und Fedora:
systemctl restart httpd
Weitere Informationen: Apache-Dokumentation
Jetzt testen: Wenn Ihre Site öffentlich verfügbar ist, testen Sie sie mit dem SSL Labs-Tool von Qualys .
Nginx Server
Wenn Sie Nginx ausführen, fügen Sie einfach die folgende Zeile unter den anderen SSL-Anweisungen in Ihre Konfiguration ein:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Wenn Sie schon dabei sind, können Sie die Konfiguration der Chiffresuite für Ihren Webserver verbessern, wie im TLS-Serverhandbuch von Mozilla beschrieben . Zum Beispiel hinzufügen:
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_prefer_server_ciphers on;
# Read up on HSTS before you enable it (recommended)
# add_header Strict-Transport-Security max-age=15768000;
Starten Sie den Server neu, z
sudo service nginx restart
Referenz: Nginx-Dokumentation
Jetzt testen: Wenn Ihre Site öffentlich verfügbar ist, testen Sie sie mit dem SSL Labs-Tool von Qualys .
Lighttpd Webserver
Lighttpd-Versionen> 1.4.28 unterstützen eine Konfigurationsoption zum Deaktivieren von SSLv2 und v3. In Lighttpd-Versionen vor 1.4.28 können Sie NUR SSLv2 deaktivieren. Bitte beachten Sie, dass Ubuntu 12.04 LTS und frühere Versionen bestenfalls lighttpd v1.4.28 installieren und daher für diese Distributionen kein einfacher Fix verfügbar ist. Daher sollte dieses Update nur für Ubuntu-Versionen größer als 12.04 verwendet werden.
Für Ubuntu Version 12.04 oder Debian 6 ist ein aktualisiertes lighttpd-Paket im openSUSE-Repository verfügbar:
http://download.opensuse.org/repositories/server:/http/Debian_6.0
Das Paket ist für Debian 6 (squeeze) gedacht, funktioniert aber auch unter 12.04 (präzise)
Bearbeiten Sie Ihre /etc/lighttpd/lighttpd.conf, um die folgenden Zeilen nach der ssl.engine = "enable"Direktive hinzuzufügen
ssl.use-sslv2 = "disable"
ssl.use-sslv3 = "disable"
sudo service lighttpd restartStarten Sie dann den lighttpd-Dienst mit a neu und führen Sie einen ssl3-Handshake-Test durch, wie in den vorherigen Abschnitten beschrieben, um sicherzustellen, dass die Änderung erfolgreich implementiert wurde.
Entnommen aus http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL .
Postfix SMTP
Bei 'opportunistischem SSL' (Verschlüsselungsrichtlinie nicht erzwungen und auch normal ist akzeptabel) müssen Sie nichts ändern. Sogar SSLv2 ist besser als normal. Wenn Sie Ihren Server sichern müssen, sollten Sie ohnehin den obligatorischen SSL-Modus verwenden.
Wenn der obligatorische SSL-Modus bereits konfiguriert ist, müssen Sie lediglich die Einstellung smtpd_tls_mandatory_protocols für eingehende Verbindungen und smtp_tls_mandatory_protocols für ausgehende Verbindungen hinzufügen / ändern :
smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
smtp_tls_mandatory_protocols=!SSLv2,!SSLv3
Wenn Sie optional auch SSLv3 für die opportunistische Verschlüsselung deaktivieren möchten (auch wenn dies, wie oben erläutert, nicht erforderlich ist), gehen Sie folgendermaßen vor:
smtpd_tls_protocols=!SSLv2,!SSLv3
smtp_tls_protocols=!SSLv2,!SSLv3
und starte Postfix neu:
sudo service postfix restart
Sendmail
(Nicht überprüfte Bearbeitung durch anonymen Benutzer. Ich bin mit Sendmail nicht vertraut. Bitte überprüfen.)
Diese Optionen werden im LOCAL_CONFIGBereich von konfiguriertsendmail.mc
LOCAL_CONFIG
O CipherList=HIGH
O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_CIPHER_SERVER_PREFERENCE
O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3
Taubenschlag
Fügen Sie in Dovecot v2.1 + Folgendes zu Ihrer /etc/dovecot/local.conf(oder einer neuen Datei in /etc/dovecot/conf.d) hinzu:
ssl_protocols = !SSLv2 !SSLv3
und starte Dovecot neu:
sudo service dovecot restart
Für ältere Versionen müssen Sie den Quellcode patchen .
Kurier-imap (imapd-ssl)
Courier-imap erlaubt SSLv3 standardmäßig unter Ubuntu 12.04 und anderen. Sie sollten es deaktivieren und stattdessen STARTTLS verwenden, um TLS zu erzwingen. Bearbeiten Sie Ihre /etc/courier/imapd-sslKonfigurationsdatei, um die folgenden Änderungen widerzuspiegeln
IMAPDSSLSTART=NO
IMAPDSTARTTLS=YES
IMAP_TLS_REQUIRED=1
TLS_PROTOCOL=TLS1
TLS_STARTTLS_PROTOCOL=TLS1
TLS_CIPHER_LIST="<take those from the Mozilla TLS Server guide!>"
HAProxy Server
SSL wird in HAProxy> = 1.5 unterstützt.
Bearbeiten Sie die /etc/haproxy.cfgDatei und finden Sie Ihre bindZeile. Anhängen no-sslv3. Zum Beispiel:
bind :443 ssl crt <crt> ciphers <ciphers> no-sslv3
Referenz: HAProxy-Dokumentation
OpenVPN
Scheint nicht betroffen zu sein ( Quelle ).
OpenVPN verwendet TLSv1.0 oder (mit> = 2.3.3) optional TLSv1.2 und ist daher nicht von POODLE betroffen.
Marionette
Puppet verwendet SSL über HTTPS, wird jedoch nicht von "Browser" -Clients verwendet, sondern nur von Puppet-Agenten, die für den angezeigten Angriffsvektor nicht anfällig sind. Es wird jedoch empfohlen, SSLv3 nur zu deaktivieren.
Meine Empfehlung ist, das Puppet-Modul von stephenrjohnson / puppetmodule zu verwenden, um Ihren Puppet-Master einzurichten, in dem ich vor einiger Zeit SSLv3 getötet habe.