Frage Wie kann ich die Sicherheitsanfälligkeit SSLv3 POODLE (CVE-2014-3566) patch / umar beiten?


Nach dem BEAST Angriff und Heartbleed Fehler, jetzt habe ich von einer neuen Sicherheitslücke in SSL / TLS gehört PUDEL. Wie schütze ich mich davor, ausgebeutet zu werden?

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

Bitte zeigen Sie mir Beispiele zur Vermeidung dieser Sicherheitsanfälligkeit.


158
2017-10-14 23:49


Ursprung


Weitere Informationen finden Sie hier SSL3 "Pudel" Sicherheitslücke - Braiam
@Braiam Ja, ich weiß, der brillante Thomas wieder! Dies ist jedoch ein sehr kryptographisch orientiertes Q & A. Dieses Q & A auf AU soll praktische und Ubuntu orientierte Informationen liefern. :-) - gertvdijk
Hä? Wie erwarten Sie eine praktischere Lösung als "Wenn Sie die Patches nicht installieren, wird Níðhöggr Ihre Milz verschlingen." - Braiam
@Braiam Vor allem: Es gibt keinen Patch (Lesen Sie meine Antwort). Ich denke, dass Thomas sich eher auf Appliances als auf DIY-Ubuntu-Webserver-Hosting bezieht. Appliances wie Load Balancer bieten in der Regel Firmware-Updates für die Änderung der Standardeinstellungen oder bieten Funktionen, um sie zu konfigurieren. In Ubuntu liegt es jedoch beim Benutzer / Administrator. - gertvdijk
Tatsächlich gibt es: Anbieter können alle SSLv3 bezogenen Code deaktivieren / entfernen, daher müssen Sie überhaupt nichts berühren. - Braiam


Antworten:


Hintergrundinformation

SSL wurde entwickelt, um den Transportlevel im Internet zu sichern. Für "das Web" aka HTTP kennen Sie dies als HTTPS, aber es wird auch für andere Anwendungsprotokolle verwendet. SSLv2 war das erste weitverbreitete Transportsicherheitsprotokoll, wurde jedoch kurz darauf unsicher gefunden. 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 Webbrowser, die 2014 veröffentlicht wurden, haben Unterstützung dafür.

Die kürzliche Entdeckung von Google-Ingenieuren weist darauf hin, dass SSLv3 nicht mehr verwendet werden sollte (wie SSLv2 vor langer Zeit aufgegeben wurde). Die Clients, die keine Verbindung zu Ihrer Website / Ihrem Dienst herstellen können, sind wahrscheinlich sehr eingeschränkt. CloudFlare angekündigt dass weniger als 0,09% ihrer Besucher sich immer noch auf SSLv3 verlassen.

Einfache Lösung: Deaktivieren Sie SSLv3.

Bietet Ubuntu ein Update?

Ja, über usn-2385-1 mit dem Zusatz der SCSV-Funktion, aber es mildert das Problem nicht vollständig Da SSLv3 nicht deaktiviert wird, funktioniert der Patch nur, wenn beide Seiten der Verbindung gepatcht wurden. Sie erhalten es durch Ihre regelmäßigen Sicherheitsupdates in Ihrem Paketmanager.

So leise SIE müssen selbst Maßnahmen ergreifen, um SSLv3 zu deaktivieren (es ist konfigurierbar). Zukünftige Versionen von Clients / Browsern werden SSLv3 höchstwahrscheinlich deaktivieren. Z.B. Firefox 34 wird dies tun.

Die vollständige Deaktivierung von SSLv3 in Ubuntu auf Implementationsebene wird wahrscheinlich auch für Nicht-HTTPS-SSL-Nutzung, die nicht so anfällig ist, etwas kaputt machen, also nehme ich an, dass die Betreuer dies nicht tun und nur dieser SCSV-Patch angewendet wird.

Warum wird die SCSV-Aktualisierung in OpenSSL über usn-2385-1 das Problem nicht mindern?

Hören Sie wirklich auf, solche Fragen zu stellen und überspringen Sie einfach ein paar Absätze und deaktivieren Sie SSLv3. Aber hey, wenn Sie nicht überzeugt sind, gehen Sie hier:

POODLE zeigt, dass SSLv3 mit CBC-Verschlüsselungen gebrochen ist, die Implementierung von SCSV ändert das nicht. SCSV stellt nur sicher, dass Sie nicht von einem TLS-Protokoll auf ein niedrigeres TLS / SSL-Protokoll herunterstufen, wie es für den Man-in-the-Middle-Angriff für die üblichen Fälle erforderlich ist.

Wenn Sie auf einen Server zugreifen müssen, der kein TLS, aber nur SSLv3 anbietet, hat Ihr Browser keine andere Wahl und muss mit SSLv3 kommunizieren, der dann ohne Downgrade-Angriff angreifbar ist.

Wenn Sie auf einen Server zugreifen müssen, der auch TLSv1 + und SSLv3 anbietet (was nicht empfohlen wird) und Sie sicherstellen möchten, dass Ihre Verbindung nicht von einem Angreifer auf SSLv3 heruntergestuft wird, dann beide Der Server und der Client benötigen diesen SCSV-Patch.

Um das Problem vollständig zu beheben, reicht die Deaktivierung von SSLv3 aus und Sie können sicher sein, dass Sie nicht heruntergestuft werden. Und Sie können nicht mit SSLv3-Servern kommunizieren.

Okay, wie deaktiviere ich SSLv3?

Siehe unten in den anwendungsspezifischen Abschnitten: Firefox, Chrome, Apache, Nginx und Postfix sind vorerst abgedeckt.

Sind nur Server oder auch Clients betroffen?

Die Sicherheitsanfälligkeit tritt auf, wenn sowohl der Server als auch der Client SSLv3 akzeptieren (auch wenn beide aufgrund eines Downgrade-Angriffs TLSv1 / TLSv1.1 / TLS1.2 ausführen können).

Als Server-Administrator sollten Sie SSLv3 deaktivieren jetzt für die Sicherheit Ihrer Benutzer.

Als Benutzer sollten Sie SSLv3 in Ihrem Browser deaktivieren jetzt um sich zu sichern, wenn Sie Webseiten besuchen, die SSLv3 noch unterstützen.

Ist dieser OpenSSL / GnuTLS / Browser spezifisch?

Nein. Es ist ein Protokoll (Design) Bug, kein Implementierungsfehler. Das bedeutet, dass Sie es nicht wirklich patchen können (es sei denn, Sie ändern das Design des alten SSLv3).

Und ja, da ist ein neues OpenSSL-Sicherheitsversion, aber lesen Sie unten (Aber ich brauche wirklich SSLv3 Unterstützung ... aus Gründen X, Y, Z!) Warum sollten Sie sich besser darauf konzentrieren, SSLv3 vollständig zu deaktivieren?

Kann ich SSLv3 auf Netzwerkebene (Firewall) beenden?

Nun ja, wahrscheinlich. Ich lege das in einem separaten Blogpost für weitere Gedanken und Arbeit. Wir mögen etwas Magie haben iptables Regel, die du benutzen kannst!

Mein Blogpost: Wie kann SSLv3 in Ihrem Netzwerk mit iptables für POODLE abgebaut werden?

Ist es nur für HTTPS oder auch für IMAP / SMTP / OpenVPN und andere Protokolle mit SSL-Unterstützung relevant?

Der aktuelle Angriffsvektor funktioniert, wie von den Forschern gezeigt, mit der Steuerung des Klartexts, der an den Server gesendet wird, indem Javascript auf dem Computer des Opfers ausgeführt wird. Dieser Vektor gilt nicht für Nicht-HTTPS-Szenarien ohne Verwendung eines Browsers.

Außerdem erlaubt ein SSL-Client normalerweise nicht, dass die Sitzung auf SSLv3 herabgestuft wird (wobei TLSv1 + in den Handshake-Funktionen zu sehen ist), aber Browser wollen sehr abwärtskompatibel sein, und das tun sie auch. Die Kombination mit dem Steuern von Klartext und die spezifische Art, wie ein HTTP-Header aufgebaut ist, macht es ausnutzbar.

Fazit: Deaktivieren Sie SSLv3 für HTTPS jetztDeaktivieren Sie SSLv3 für andere Dienste in Ihrem nächsten Dienstfenster.

Was ist der Effekt? Muss ich mein Serverzertifikat widerrufen und neu generieren? (Wie bei Heartbleed)

Nein, Sie müssen Ihre Zertifikate dafür nicht rotieren lassen. Durch die Sicherheitsanfälligkeit wird die Plaintext-Wiederherstellung aus den Sitzungsdaten ausgeschlossen. Sie bietet keinen Zugriff auf geheime Schlüssel (weder den Sitzungs- noch den Zertifikatsschlüssel).

Ein Angreifer ist höchstwahrscheinlich nur in der Lage, die Klartext-Header wie Sitzungs-Cookies zu stehlen, um ausgeführt zu werden Session-Hijacking. Eine zusätzliche Einschränkung ist die Notwendigkeit für eine vollständige (aktive) MitM Angriff.

Kann ich noch etwas tun, um meine SSL-Konfiguration im Allgemeinen zu verbessern?

Als Benutzer, neben der Deaktivierung von SSLv3 in Ihrem Browser, nicht wirklich. Nun, installieren Sie immer die neuesten Sicherheitsupdates.

Für Server folgen Mozillas TLS-Server-Handbuch. Und teste mit Qualys 'SSL Labs Test. Es ist wirklich nicht schwer, eine A + Bewertung auf Ihrer Website zu erhalten. Aktualisieren Sie einfach Ihre Pakete und implementieren Sie die Empfehlungen aus dem Leitfaden von Mozilla.

Aber ich brauche wirklich SSLv3 Unterstützung ... aus Gründen X, Y, Z! Was jetzt?

Nun, es gibt einen Patch, der den Downgrade-Angriff von TLSv1-fähigen Clients umgeht, der SSLv3-Fallback-Schutz genannt wird. Es wird übrigens auch die Sicherheit von TLSv1 + verbessern (Downgrade-Angriff ist schwieriger / unmöglich). Es wird als Backport von einer neueren OpenSSL-Version in der Ubuntu Security Advisory angeboten usn-2385-1.

Großer Haken: Sowohl Clients als auch Server benötigen diesen Patch, um zu funktionieren. Also, meiner Meinung nach, während Sie sowohl Clients als auch Server aktualisieren, sollten Sie trotzdem auf TLSv1 + upgraden.

Bitte, bitte, ziehen Sie SSLv3 einfach in Ihrem Netzwerk vorerst zurück. Bemüht euch, die Sicherheitsstandards zu verbessern und SSLv3 einfach zu entfernen.

Ich habe von der SCSV-Unterstützung gehört, um den Protokoll-Downgrade-Angriff zu eliminieren. Brauche ich es?

Nur wenn Sie wirklich SSLv3 aus irgendeinem Grund brauchen, aber es verbessert auch die Sicherheit in TLSv1 +, also würde ich Ihnen empfehlen, es 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.

Test-Schwachstelle für privat gehostete Sites (z. B. Intranet / Offline).

Ihre Server sind 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, ist sslv3 aktiviert. Wenn es fehlschlägt, ist es deaktiviert. Wenn es fehlschlägt, solltest du etwas sehen wie:

    error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
    
  • Verwenden nmap:

    nmap --script ssl-enum-ciphers -p 443 myhostname.tld
    

    Es sollte ausgebenSSLv3: No supported ciphers found". Passen Sie für Ihren Hostnamen / Port an.

  • Verwenden cipherScan. Clone / lade die Binärdatei herunter und führe sie aus:

    ./cipherscan myhostname.tld
    

    Es sollte nicht Listen Sie alles mit SSLv3 in der Spalte 'protokolle' auf.


Firefox-Browser

Öffnen about:config, finden security.tls.version.min und setze 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 somit keine Aktion (Quelle). Im Moment des Schreibens ist jedoch 33 gerade veröffentlicht und 34 ist für den 25. November festgelegt.


Google Chrome (Linux)

Bearbeiten Sie die /usr/share/applications/google-chrome.desktop Datei, z.B.

sudo nano /usr/share/applications/google-chrome.desktop

Bearbeiten alle Linien beginnen mit Exec= einschließen --ssl-version-min=tls1.

Z.B. eine Linie wie

Exec=/usr/bin/google-chrome-stable %U

wird

Exec=/usr/bin/google-chrome-stable --ssl-version-min=tls1 %U

Stellen Sie sicher, dass der Browser vollständig geschlossen ist (Chrome-Apps halten Ihren Browser möglicherweise im Hintergrund aktiv!).

Hinweis: Möglicherweise müssen Sie dieses Update für jedes google-chrome-Paket wiederholen und dies überschreiben .desktop Launcher-Datei. Ein Google Chrome- oder Chromium-Browser mit standardmäßig deaktiviertem SSLv3 ist zum Zeitpunkt des Verfassens 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 ist die Datei /etc/apache2/mods-available/ssl.conf. Auf CentOS und Fedora ist 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

Dies ermöglicht alle Protokolle außer SSLv2 und SSLv3.

Wenn Sie schon dabei sind, sollten Sie in Erwägung ziehen, die Konfiguration der CipherSuite für Ihren Webserver zu verbessern, wie in der Beschreibung beschrieben Mozillas TLS-Server-Handbuch. Fügen Sie zum Beispiel hinzu:

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"

Dann überprüfe, ob die neue Konfiguration korrekt ist (keine Tippfehler etc.):

sudo apache2ctl configtest

Und starten Sie den Server neu, z.

sudo service apache2 restart

Auf CentOS und Fedora:

systemctl restart httpd

Mehr Info: Apache-Dokumentation

Testen Sie es jetzt: Wenn Ihre Site öffentlich verfügbar ist, testen Sie sie mit Das SSL Labs-Tool von Qualys.


Nginx-Server

Wenn Sie Nginx ausführen, fügen Sie einfach die folgende Zeile in Ihre Konfiguration zwischen den anderen SSL-Direktiven ein:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Wenn Sie schon dabei sind, sollten Sie in Erwägung ziehen, die Konfiguration der CipherSuite für Ihren Webserver zu verbessern, wie in der Beschreibung beschrieben Mozillas TLS-Server-Handbuch. Fügen Sie zum Beispiel hinzu:

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;

Und starten Sie den Server neu, z.

sudo service nginx restart

Referenz: Nginx-Dokumentation

Testen Sie es jetzt: Wenn Ihre Site öffentlich verfügbar ist, testen Sie sie mit Das SSL Labs-Tool von Qualys.


Lighttpd Webserver

Lighttpd-Versionen> 1.4.28 unterstützen eine Konfigurationsoption zum Deaktivieren von SSLv2 und v3. Lighttpd Releases vor 1.4.28 erlauben Ihnen, SSLv2 NUR zu deaktivieren. Bitte beachten Sie, dass Ubuntu 12.04 LTS und früher bestenfalls Lighttpd v1.4.28 installieren und daher für diese Distributionen keine einfache Lösung verfügbar ist.  Daher sollte dieser Fix 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 vom 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 am 12.04 (Precise)

Bearbeiten Sie Ihre /etc/lighttpd/lighttpd.conf um die folgenden Zeilen nach der ssl.engine = "enable" Richtlinie

ssl.use-sslv2          = "disable"
ssl.use-sslv3          = "disable"

Dann sollten Sie den lighttpd-Dienst mit a neu starten sudo service lighttpd restart Führen Sie wie in den vorherigen Abschnitten beschrieben einen ssl3-Handshake-Test durch, um sicherzustellen, dass die Änderung erfolgreich implementiert wurde.

Genommen von http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL.


Postfix SMTP

Bei 'opportunistischem SSL' (die Verschlüsselungsrichtlinie wird nicht erzwungen und die Plain ist auch akzeptabel) müssen Sie nichts ändern. Selbst SSLv2 ist besser als einfach. Wenn Sie also Ihren Server sichern müssen, sollten Sie trotzdem den "obligatorischen SSL" -Modus verwenden.

Wenn der 'obligatorische SSL'-Modus bereits konfiguriert ist, fügen Sie einfach den / hinzu smtpd_tls_mandatory_protocols Einstellung für eingehende Verbindungen und smtp_tls_mandatory_protocols für ausgehende Verbindungen:

smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
smtp_tls_mandatory_protocols=!SSLv2,!SSLv3

Optional, wenn Sie SSLv3 auch für opportunistische Verschlüsselung deaktivieren möchten (auch wenn dies nicht notwendig ist, wie oben erklärt), tun Sie dies auch so:

smtpd_tls_protocols=!SSLv2,!SSLv3
smtp_tls_protocols=!SSLv2,!SSLv3

und starte Postfix neu:

sudo service postfix restart

Sendmail

(Ungeprüfte Bearbeitung durch anonymen Benutzer, ich bin mit Sendmail nicht zufrieden, bitte bestätigen Sie es.)

Diese Optionen sind in den Einstellungen konfiguriert LOCAL_CONFIG Abschnitt von Ihrem sendmail.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

Dovecot

In Dovecot v2.1 + fügen Sie Folgendes zu Ihrem /etc/dovecot/local.conf (oder eine neue Datei in /etc/dovecot/conf.d):

ssl_protocols = !SSLv2 !SSLv3

und starte Dovecot neu:

sudo service dovecot restart

Für ältere Versionen müssen Sie patch den Quellcode.


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-ssl Konfigurationsdatei, 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.cfg Datei und finde deine bind Linie. Anhängen no-sslv3. Beispielsweise:

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 wird daher nicht von POODLE beeinflusst.


Marionette

Puppet verwendet SSL über HTTPS, wird aber nicht von Browser-Clients verwendet, sondern nur von Puppet-Agenten, die nicht anfällig für den angezeigten Angriffsvektor sind. Es ist jedoch die beste Vorgehensweise, SSLv3 einfach zu deaktivieren.

Meine Empfehlung ist die Verwendung der stephenjohnson / Puppenmodul Puppet-Modul zum Einrichten Ihres Puppet-Masters in dem Ich habe SSLv3 getötet vor einiger Zeit.


210
2017-10-14 23:49



Diese Antwort wurde sehr schnell nach der Veröffentlichung der Sicherheitslücke erstellt. Dort kann es immer noch Fehler geben - wie immer, fühlen Sie sich frei, zu bearbeiten / zu verbessern. - gertvdijk
Nginx config sollte keinen Doppelpunkt nach ssl_protocols Direktive haben - Michelle
Ok, für Firefox glaube ich Dies ist was los ist. - fuglede
Dieser Blogbeitrag von Mozilla Security schlägt vor, zu installieren dieses Add-on anstatt die Einstellungen manuell anzupassen. - legoscia
@muru Hier ist ein Anfang auf SSLv3 auf Firewall-Ebene zu töten. blog.g3rt.nl/take-down-sslv3-using-iptables.html - gertvdijk


Möglicherweise nicht ubuntuspezifisch, aber um die Poodle Schwachstelle in Node.js zu umgehen, können Sie die secureOptions zu require('constants').SSL_OP_NO_SSLv3 wenn Sie einen https oder tls Server erstellen.

Sehen https://gist.github.com/3rd-Eden/715522f6950044da45d8 für zusätzliche Informationen


4
2017-10-15 08:59



IMO sollte man HTTP (S) nicht direkt mit Node / Python / Ruby oder ähnlichem in Verbindung bringen. Stellen Sie ein anständiges HTTPd wie Apache / Nginx / ... - gertvdijk
Ja, Sie sollten nicht direkt aussetzen. Sprachen sind nicht so gut mit TCP-Layer-HTTP, aber sie rocken Sockets. Lass nginx es von einem Socket lesen. :-) - jrg♦
Dies hat keine Abstimmung verdient. Es gibt viele Fälle, in denen TLS neben dem Hosting eines HTTP-Servers verwendet wird. - psanford
@gertvdijk & jrg Node.js ist keine Sprache. Es ist ein Framework für den Aufbau skalierbarer Netzwerkanwendungen. Und wenn Sie sagen, dass Sie Node.js hinter einen Apache-Server stellen sollten (und es sogar "anständig" nennen), wird bereits klar, dass Sie absolut keine Ahnung haben, wovon Sie reden. Zu sagen, dass sie nicht gut mit tpc / http sind, ist offensichtlich persönliche Voreingenommenheit. Bitte bleiben Sie einfach auf dem Laufenden, anstatt auf kindliche Abstimmungs-Technologie, die Sie nicht verstehen. - 3rdEden
@ 3rdEden Nun, vielleicht war meine Bemerkung etwas verallgemeinernd, aber hier sind ein paar Notizen, die ich gerne machen würde. 1) Ich habe nicht downvote, 2) mein Kommentar war eine sanfte "IMO", 3) Vielleicht ist es nur meine Sicherheit Hintergrund, aber ich habe gelernt, dass man nicht ein Anwendungsrahmen direkt an 80/443 in der Welt aussetzen sollte Produktion. (außer zu Demonstrationszwecken). 4) Ich sehe nicht, wie Ihr Beitrag eine "Antwort" auf die Frage für den allgemeinen Ask Ubuntu-Besucher ist; Es ist nur sehr spezifisch für einen bestimmten Fall von Node.js-Bereitstellungen. - gertvdijk


Die "Reparatur" für Kurier deaktiviert Tls 1.1 und Tls 1.2. Es scheint keinen Weg zu geben, Kurier mit Tls 1.1 oder höher auszuführen. Ein PCI-Scan auf Ihrem Server kommt möglicherweise mit der folgenden Empfehlung zurück:

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


0
2018-02-27 14:45





Da die POODLE-Schwachstelle ein Konstruktionsfehler im Protokoll selbst und kein Implementierungsfehler ist, wird es keine Patches geben. Dies kann nur durch Deaktivieren von SSLv3 auf dem Apache-Server behoben werden. Fügen Sie die folgenden Zeilen in ssl.conf hinzu und führen Sie einen grazilen 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"

-1
2017-10-15 22:55



-1 für RC4 und nicht-funktionale ECDSA, da die meisten Menschen RSA-Zertifikate haben. Bitte lesen Sie, wie Sie Ihren Server richtig konfigurieren. wiki.mozilla.org/Security/Server_Side_TLS - gertvdijk
@gertvdijk Ich stimme dir mit RC4 zu, aber es schadet nicht, ECDSA-Suites einzuschließen. Es ist harmlos, wenn Sie nur ein RSA-Zertifikat haben und Ihnen die Mühe ersparen, Ihre Konfiguration zu reparieren, wenn Sie später ein ECDSA-Zertifikat erhalten. - Matt Nordhoff
@MattNordhoff Fair genug, aber was ich meine ist, dass nicht viele Chiffren für eine regelmäßige RSA-Zertifikat-basierte Konfiguration übrig sind. Es wird in den meisten Browsern funktionieren, aber möglicherweise Kompatibilitätsprobleme auftreten. - gertvdijk
Entferne definitiv RC4 von dieser Liste, das ist nicht sicher. Bleib bei den anderen, wenn du kannst. 3DES ist schwach, aber ich habe das an einem bestimmten Ort aus Gründen der Kompatibilität aktiviert. Ich hasse es zu tun, weil es schwach ist, aber zumindest ist es nicht wirklich kaputt ... - Brian Knoblauch