Deaktivieren von RC4 in der SSL-Verschlüsselungssuite eines Apache-Servers

Question

Deaktivieren von RC4 in der SSL-Verschlüsselungssuite eines Apache-Servers

Bitte beachten Sie die Bearbeitungsabschnitte in meiner eigenen Antwort; Sie enthalten eine Erklärung zu diesem Rätsel.

Ich versuche, RC4 für einen Apache 2.2.9-Server zu deaktivieren, der auf einem CentOS 6.5 VPS ausgeführt wird, und ich kann anscheinend keinen Erfolg haben.

Ein kürzlich erworbenes Business-validiertes Zertifikat ist installiert und SSL-Verbindungen laufen einwandfrei, aber ich wollte die Dinge so gut wie möglich konfigurieren, um" die Sicherheit zu verhärten", wie es einige Tutorials ausdrücken.

Überprüfen der konfiguration mit Qualys SSL Labs zeigt die Ergebnisseite "Dieser Server akzeptiert die RC4-Chiffre, die schwach ist. Klasse auf B begrenzt "

Ich habe dies jedoch in ssl eingefügt.conf:

 SSLCipherSuite HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!SSLv2:!SSLv3

Ich habe das Skript in der Antwort auf diese Frage in einer Datei mit dem Namen test-ssl-ciphers.sh und änderte die IP-Adresse in eine Loopback-Adresse. Dies ist das Ergebnis von ./test-ssl-ciphers.sh | grep -i "RC4":

Testing ECDHE-RSA-RC4-SHA...NO (sslv3 alert handshake failure)
Testing ECDHE-ECDSA-RC4-SHA...NO (sslv3 alert handshake failure)
Testing AECDH-RC4-SHA...NO (sslv3 alert handshake failure)
Testing ADH-RC4-MD5...NO (sslv3 alert handshake failure)
Testing ECDH-RSA-RC4-SHA...NO (sslv3 alert handshake failure)
Testing ECDH-ECDSA-RC4-SHA...NO (sslv3 alert handshake failure)
Testing RC4-SHA...NO (sslv3 alert handshake failure)
Testing RC4-MD5...NO (sslv3 alert handshake failure)
Testing RC4-MD5...NO (sslv3 alert handshake failure)
Testing PSK-RC4-SHA...NO (no ciphers available)
Testing KRB5-RC4-SHA...NO (no ciphers available)
Testing KRB5-RC4-MD5...NO (no ciphers available)
Testing EXP-ADH-RC4-MD5...NO (sslv3 alert handshake failure)
Testing EXP-RC4-MD5...NO (sslv3 alert handshake failure)
Testing EXP-RC4-MD5...NO (sslv3 alert handshake failure)
Testing EXP-KRB5-RC4-SHA...NO (no ciphers available)
Testing EXP-KRB5-RC4-MD5...NO (no ciphers available)

Jede dieser Zeilen enthält "NEIN", was laut Skript bedeutet, dass der Server dies tut unterstützt die angegebene Verschlüsselungskombination nicht.

Außerdem gibt mir der Befehl grep -i -r "RC4" /etc/httpd nur das oben erwähnte ssl.conf-Datei.

Außerdem zeigt das Ausführen von openssl ciphers -V in meiner Verschlüsselungssuite überhaupt keine RC4-Chiffren an, was angesichts der Konfigurationszeichenfolge sinnvoll ist.

Ich bin daher irgendwie verloren, warum die SSL-Check-Websites mir sagen, dass "der Server RC4 akzeptiert". Sie listen sogar die folgenden Chiffren als akzeptiert auf:

TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA

Hat jemand eine mögliche Erklärung? Was mache ich etwas falsch? Vielleicht gibt es einen anderen Ort, wo die Unterstützung von RC4 oder "Akzeptanz" konfiguriert werden?

Dank.

[BEARBEITEN] Mit einem CentOS 6.6 in einer virtuellen Maschine zu Hause habe ich das Skript erneut mit meinem VPS unter Verwendung seines Domänennamens anstelle der Loopback-Adresse ausgeführt. Dieses Setup impliziert, dass die Liste der Chiffren von der openssl-Instanz in der VM bereitgestellt wird: Ich habe immer noch keine RC4 unter den Chiffren, die JA ergeben.

21

ssl openssl apache-http-server

Author: AbVog, 2015-01-19

Source

5 answers

SSLCipherSuite HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!SSLv2:!SSLv3
                                                                    ^^^^^^^

Schlechte Idee. Das Deaktivieren aller SSLv3-Chiffren führt zum Deaktivieren der mit TLS1.0 und TLS1.1 verwendbaren Chiffren und lässt nur wenige mit TLS1.2 neu eingeführte Chiffren übrig (wenn Ihr Server TLS1.2 unterstützt)

Ich bin daher irgendwie verloren, warum die SSL-Check-Websites mir sagen, dass "der Server RC4 akzeptiert". Sie listen sogar die folgenden Chiffren als akzeptiert auf:

Stellen Sie sicher, dass sowohl die lokalen als auch die externen Tests auf denselben Server (IP-Adresse) zugreifen. Ich habe viele Websites gesehen, auf denen sich example.com auf einem anderen Host als www.example.com befindet, und daher unterscheiden sich die Tests.

6

Author: Steffen Ullrich,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/techietown.info/template/agent.layouts/content.php on line 61
2015-01-19 18:04:12

Qualys SSL Labs scheint sehr empfindlich auf Standardhosts usw. zu reagieren. Überprüfen Sie, ob ALLE Ihre HTTPS-VirtualHosts auf dieser IP-Adresse genau die gleichen Einstellungen verwenden (abgesehen von Zertifikatdateien), ich hatte ein ähnliches Problem, bei dem einige der Qualys-Tests gegen meinen gezielten VirtualHost getestet wurden und einige der Tests einen Standard-VirtualHost aufzunehmen schienen. Mein Ziel-Vhost hatte nur eine einzige Chiffre aktiviert, aber Qualys fand eine viel größere Liste als der Standard-Vhost.

Ich fand auch eine besser aussehende skript hier, das gründlichere Informationen zu SSL-Tests enthält.

2

Author: Geoff,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/techietown.info/template/agent.layouts/content.php on line 61
2015-01-27 01:44:39

Habe gerade nach einer meiner Seiten gesucht. Auf der Grundlage der Antwort von @AbVog stellte ich fest, dass sich meine Anweisungen tatsächlich nur im Standard-vhost befanden. Als ich die Direktiven in den globalen Kontext verschoben habe, war alles gut.

Nebenbei stieß ich auch auf https://cipherli.st/, das eine gute Liste von SSL-Konfigurationen für eine Reihe verschiedener Pakete enthält. Die aktuelle Empfehlung für Apache lautet wie folgt:

SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff

# Requires Apache >= 2.4
SSLCompression off 
SSLSessionTickets Off
SSLUseStapling on 
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"

2

Author: boyvinall,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/techietown.info/template/agent.layouts/content.php on line 61
2016-03-31 13:56:33

Auf meinem Fedora 25 mit Apache/2.4.25 werden Chiffren von den Krypto-Richtlinien behandelt (siehe /etc/cryptopolicies/Backends). Das Standard-Setup hat RC4 vollständig deaktiviert, so dass keine Notwendigkeit für Manipulationen mit Chiffren im Apache-Setup. Außer sicherzustellen, dass Sie das neueste SSL verwenden.conf, da es nicht standardmäßig installiert ist, sondern als SSL belassen wird.conf.rpmnew in der conf.d Verzeichnis.

Um SSL zu konfigurieren, musste ich nur Zertifikate, Servernamen und DocumentRoot angeben. Für Eichhörnchen ist das is.

SSLCertificateFile /etc/letsencrypt/live/mail.xxxx.dk/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mail.xxxx.dk/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/mail.xxxx.dk/chain.pem
SSLCACertificateFile /etc/letsencrypt/live/mail.xxxx.dk/fullchain.pem
ServerName mail.xxxx.dk:443
DocumentRoot "/usr/share/squirrelmail"

0

Author: John Damm Sørensen,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/techietown.info/template/agent.layouts/content.php on line 61
2017-01-25 07:14:52

score 17 · Accepted Answer

Bei der Installation des erneuerten Zertifikats stellte ich fest, dass das Problem dadurch verursacht wurde, dass (für die Domäne und für jede Unterdomäne) in ISPConfig der gesamte Datensatz angegeben wurde, der für HTTPS erforderlich ist: Zertifikat, privater Schlüssel, CA-Kette usw.

Anders ausgedrückt: Das Entfernen des Datensatzes führte zum Qualys-Test, um die Domäne A zu bewerten und gleichzeitig die Warnungen vor RC4 zu entfernen. Das Zurücksetzen der Details führt dazu, dass die Warnungen zurückkommen und die Note wieder auf B begrenzt wird, was lässt keinen Platz für Zweifel an der Kausalität link.

Es ist, als ob die Angabe der Details für jeden vhost irgendwie eine neue Umgebung erstellt hätte, in der einige Standardeinstellungen die in ssl angegebene Verschlüsselungssuite überschrieben haben.conf. Seltsam.

Die Lösung besteht darin, die SSLCipherSuite-Spezifikation in den [[12]}Apache-Direktiven Textarea für jeden vhost hinzuzufügen. Dies ist, was ich in der Konfiguration habe, die mir eine A-Note gibt:

SSLProtocol ALL -SSLv2 -SSLv3
SSLHonorCipherOrder on
# Compression is disabled by default on my distribution (CentOS 6)
# SSLCompression off 
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

BEARBEITEN (2017-05-16): Eine zusätzliche zu finden über dieses problem: die Angabe von SSLCipherSuite ist obligatorisch. Ich kann nicht verstehen, warum diese spezifische Direktive, obwohl auf Serverebene angegeben, nicht automatisch für virtuelle Hostkonfigurationen gilt. Ich verwende Apache 2.2.15 unter CentOS 6.9.

BEARBEITEN (2018-06-18): Weitere Informationen. Ich habe gerade festgestellt, dass die Direktive SSLCipherSuite ein einziges Mal angegeben werden kann und für alle virtuellen Hosts gilt: In der Konfigurationsdatei base mod_ssl (unter CentOS 6 lautet die Datei gefunden bei /etc/httpd/conf.d/ssl.conf), müssen Sie einfach die Direktive außerhalb von des Standard-Virtualhosts angeben. Die Apache 2.2-Dokumentation besagt, dass der Standardwert dieser Direktive SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP ist. Ich gehe davon aus, dass hier die RC4-Chiffre herkommt: In Ermangelung einer Spezifikation, was für mich der Fall war, da sich keine Spezifikation im "globalen" Kontext befand, gilt der Standardwert. Dieses Verständnis beendet, was für mich ein Rätsel war. Ironischerweise bin ich dabei, zu CentOS 7 zu wechseln, wenn ich finden Sie diese Erklärung! HTH.