Wie kann ich die Sicherheitsanfälligkeit in SSLv3 POODLE (CVE-2014-3566) beheben / umgehen?

157

Nach dem BEAST-Angriff und dem Heartbleed-Bug habe ich jetzt von einer neuen Sicherheitslücke in SSL / TLS namens POODLE gehört . Wie schütze ich mich vor Ausbeutung?

  • Sind nur Server oder auch Clients betroffen?
  • Ist das OpenSSL / GnuTLS-spezifisch?
  • Welche Dienstleistungen sind betroffen? Nur HTTPS oder auch IMAPS, SMTPS, OpenVPN usw.?

Bitte zeigen Sie mir Beispiele, wie Sie diese Sicherheitsanfälligkeit vermeiden können.

gertvdijk
quelle
2
Weitere Informationen finden Sie hier Sicherheitsanfälligkeit in SSL3 "Pudel"
Braiam,
1
@Braiam Ja ich weiß, der geniale Thomas schon wieder! Dies ist jedoch eine sehr kryptografisch ausgerichtete Frage und Antwort. Diese Fragen und Antworten zu AU sollen praktische und Ubuntu-orientierte Informationen liefern. :-)
gertvdijk
10
Huh? Wie erwarten Sie eine praktischere Lösung als "Wenn Sie die Patches nicht installieren, verschlingt Níðhöggr Ihre Milz."
Braiam
2
@Braiam Zuallererst: Es gibt keinen Patch (lies meine Antwort). Ich denke, dass Thomas sich eher auf Appliances als auf das Hosting von DIY-Ubuntu-Webservern bezieht. Appliances wie Load Balancer bieten in der Regel Firmware-Updates zum Ändern der Standardeinstellungen an oder bieten Funktionen, um diese konfigurieren zu können. In Ubuntu ist es jedoch alles Sache des Benutzers / Administrators.
Gertvdijk
Tatsächlich gibt es: Anbieter können den gesamten SSLv3-bezogenen Code deaktivieren / entfernen, sodass Sie überhaupt nichts anfassen müssen.
Braiam

Antworten:

209

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.

gertvdijk
quelle
7
Diese Antwort wurde sehr schnell nach der Veröffentlichung der Sicherheitsanfälligkeit erstellt. Es kann immer noch Fehler geben - wie immer können Sie diese gerne bearbeiten / verbessern.
Gertvdijk
1
Die Nginx-Konfiguration sollte nach der Anweisung ssl_protocols keinen Doppelpunkt haben
Michelle
1
Okay, für Firefox Ich glaube , das ist , was los ist .
Fuglede
4
In diesem Blogeintrag zu Mozilla Security wird vorgeschlagen , dieses Add-On zu installieren , anstatt die Einstellungen manuell zu ändern.
Legoscia
1
@muru Hier ist ein Einstieg in das Killen von SSLv3 auf Firewall-Ebene. blog.g3rt.nl/take-down-sslv3-using-iptables.html
gertvdijk
4

Könnte nicht ubuntu spezifisch sein , aber um rund um den Pudel Verwundbarkeit in Node.js arbeiten Sie die festlegen können , secureOptionsum require('constants').SSL_OP_NO_SSLv3beim Erstellen eines https oder tls - Server.

Weitere Informationen finden Sie unter https://gist.github.com/3rd-Eden/715522f6950044da45d8

3rdEden
quelle
1
IMO sollten Sie HTTP (S) nicht mit Node / Python / Ruby oder Ähnlichem direkt verfügbar machen.
Stellen
Ja, Sie sollten nicht direkt belichten. Sprachen sind nicht so gut mit TCP-Layer-HTTP, aber sie rocken Sockets. Lassen Sie es Nginx aus einem Socket lesen. :-)
jrg
4
Dies hat keine Gegenstimme verdient. Es gibt viele Fälle, in denen neben dem Hosting eines http-Servers auch tls verwendet wird.
Psanford
@gertvdijk & jrg Node.js ist keine Sprache. Es ist ein Framework zum Erstellen skalierbarer Netzwerkanwendungen. Und wenn Sie angeben, dass Sie Node.js hinter einen Apache-Server stellen sollten (und dies sogar als "anständig" bezeichnen), wird bereits deutlich, dass Sie absolut keine Ahnung haben, wovon Sie sprechen. Die Aussage, dass sie mit tpc / http nicht gut umgehen, ist offensichtlich eine persönliche Befangenheit. Bitte bleiben Sie bei dem Thema, das Sie nicht verstehen.
3rdEden
@ 3rdEden Naja, vielleicht war meine Bemerkung etwas verallgemeinernd, aber hier sind ein paar Anmerkungen, die ich gerne machen würde. 1) Ich habe nicht abgelehnt, 2) mein Kommentar war ein sanftes 'IMO', 3) Vielleicht ist es nur mein Hintergrund in Sachen Sicherheit, aber ich habe gelernt, dass man ein Anwendungsframework nicht direkt in 80/443 der Welt zugänglich machen sollte Produktion. (außer zu Demonstrationszwecken). 4) Ich verstehe nicht, wie Ihr Beitrag eine "Antwort" auf die Frage für den allgemeinen Besucher von Ask Ubuntu ist. Es ist nur sehr, sehr spezifisch für einen bestimmten Fall von Node.js-Bereitstellungen.
Gertvdijk
0

Das "Update" für Kurier deaktiviert TLS 1.1 und TLS 1.2. Es scheint keine Möglichkeit zu geben, Kurierdienste mit tls 1.1 oder höher auszuführen. Ein PCI-Scan auf Ihrem Server kann folgende Empfehlung enthalten:

Konfigurieren Sie SSL / TLS-Server so, dass TLS 1.1 oder TLS 1.2 nur verwendet wird, wenn dies unterstützt wird. Konfigurieren Sie SSL / TLS-Server so, dass nur Cipher Suites unterstützt werden, die keine Blockchiffren verwenden.

PrgWiz
quelle
-1

Da die POODLE-Sicherheitsanfälligkeit ein Entwurfsfehler im Protokoll selbst und kein Implementierungsfehler ist, gibt es keine Patches. Die einzige Möglichkeit, dies zu verringern, besteht darin, SSLv3 auf dem Apache-Server zu deaktivieren. Fügen Sie die folgenden Zeilen in ssl.conf ein und führen Sie einen ordnungsgemäßen Apache-Neustart durch.

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"
Lal Krishna
quelle
1
-1 für die Einbeziehung von RC4 und nicht funktionsfähigem ECDSA, da die meisten Personen RSA-Zertifikate besitzen. Lesen Sie einfach nach, wie Sie Ihren Server richtig konfigurieren. wiki.mozilla.org/Security/Server_Side_TLS
gertvdijk
2
@gertvdijk Ich stimme Ihnen in Bezug auf RC4 zu, aber es tut nicht weh, ECDSA-Suiten einzuschließen. Es ist harmlos, wenn Sie nur ein RSA-Zertifikat haben und erspart Ihnen die Mühe, Ihre Konfiguration zu reparieren, wenn Sie später ein ECDSA-Zertifikat erhalten.
Matt Nordhoff
@MattNordhoff Fair genug, aber ich meine, dass nicht viele Chiffren für eine reguläre Konfiguration auf Basis von RSA-Zertifikaten übrig bleiben. Es funktioniert in den meisten Browsern, es können jedoch Kompatibilitätsprobleme auftreten.
Gertvdijk
Auf jeden Fall RC4 aus dieser Liste entfernen, das ist nicht sicher. Bleib bei den verbleibenden, wenn du kannst. 3DES ist schwach, aber ich habe es aus Kompatibilitätsgründen an einer bestimmten Stelle aktiviert. Ich hasse es, es zu tun, da es schwach ist, aber zumindest ist es nicht wirklich kaputt ...
Brian Knoblauch