Ich erhalte die Fehlermeldung: SSL3_GET_RECORD: Entschlüsselung fehlgeschlagen oder fehlerhafter Mac

Ich habe meinen eigenen Server (auf dem ich laufe Apache/2.4.27) und heute habe ich festgestellt, dass ich von (Brave und Google Chrome - verschiedene Computer) diesen Fehler von meinen Websites bekomme.

This site can’t provide a secure connection

mywebsite.com sent an invalid response.
ERR_SSL_PROTOCOL_ERROR

Und das Seltsame ist, dass ich diesen Fehler bei jedem fünften Klick auf meiner Website erhalte.

Aus meiner Conf-Datei:

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/mywebsite/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mywebsite/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/mywebsite/chain.pem
SSLCompression off

von options-ssl-apache.conf;

SSLProtocol             all -SSLv2 -SSLv3
SSLCipherSuite          EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLHonorCipherOrder     on
SSLCompression          off

Ich habe die Protokolldatei von der Website überprüft, aber nichts, auch nichts hier; /var/log/apache2/error.log

Ich versuche herauszufinden, was diesen Fehler verursacht. Gibt es Ideen, wo ich mehr Informationen finden kann oder noch besser, wie ich dieses Problem lösen kann?

BEARBEITEN:

Wenn ich es versuche openssl s_client -connect mywebsite.com:443, wird es zurückkehren:

Ich benutze: OpenSSL 1.1.0f

CONNECTED(00000003)

...

3073276480:error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac:../ssl/record/ssl3_record.c:469:

EINE ANDERE BEARBEITUNG:

Wie @quadruplebucky vorschlug, änderte ich options-ssl-apache.conf in:

SSLProtocol             all -SSLv2 -SSLv3
SSLCipherSuite           HIGH:MEDIUM:!aNULL:!MD5:!SSLv3:!SSLv2:!TLSv1
SSLHonorCipherOrder     on
SSLCompression          off

#SSLSessionTickets       off

Ich habe auch versucht hinzuzufügen , SSLProtocol all -SSLv2 -SSLv3in meine Virtual conf - Datei, und in der gleichen Zeit habe ich ändern paar Dinge hier;/etc/apache2/mods-available/ssl.conf

#SSLCipherSuite HIGH:!aNULL
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SSLv3:!SSLv2:!TLSv1

SSLHonorCipherOrder on

#   The protocols to enable.
#   Available values: all, SSLv3, TLSv1, TLSv1.1, TLSv1.2
#   SSL v2  is no longer supported
SSLProtocol all -SSLv2 -SSLv3

BEARBEITEN:

Nach dem Ändern von LogLevel wird Folgendes Infozurückgegeben:

[Sat Jul 08 13:34:53.374307 2017] [ssl:info] [pid 8710] [client] AH02008: SSL library error 1 in handshake (server mywebsite:443)
[Sat Jul 08 13:34:53.374717 2017] [ssl:info] [pid 8710] SSL Library Error: error:140940F4:SSL routines:ssl3_read_bytes:unexpected message
[Sat Jul 08 13:34:53.374750 2017] [ssl:info] [pid 8710] [client] AH01998: Connection closed to child 1 with abortive shutdown (server mywebsite:443)

BEARBEITEN:

Wenn ich mit der Option -crlf laufe, dann wie folgt:

openssl s_client -crlf -connect mywebsite:443

Ich bekomme keinen Fehler?

Eine weitere Sache, wenn ich LogLevel in Debug ändere, erhalte ich vor diesem Fehler Folgendes:

[Tue Jul 11 23:00:38.641568 2017] [core:debug] [pid 26561] protocol.c(1273): [client 188.64.25.162:23165] AH00566: request failed: malformed request line
[Tue Jul 11 23:00:38.641634 2017] [headers:debug] [pid 26561] mod_headers.c(900): AH01503: headers: ap_headers_error_filter()

Danach tritt derselbe Fehler auf:

SSL Library Error: error:140940F4:SSL routines:ssl3_read_bytes:unexpected message

openssl version
OpenSSL 1.1.0f  25 May 2017

Sie können nicht von diesem Fehler feststellen , ob Ihr Server SSLv3 oder TLSv1 verhandelt (Sie vielleicht einen Blick auf haben wollen diese Frage auf Unix & Linux und stellen Sie sicher , es ist deaktiviert überall in Apache ...) --- die 1.1.0f Quellcode hier auf GitHub verwischt absichtlich die beiden ...

   if (enc_err < 0) {
    /*
     * A separate 'decryption_failed' alert was introduced with TLS 1.0,
     * SSL 3.0 only has 'bad_record_mac'.  But unless a decryption
     * failure is directly visible from the ciphertext anyway, we should
     * not reveal which kind of error occurred -- this might become
     * visible to an attacker (e.g. via a logfile)
     */
    al = SSL_AD_BAD_RECORD_MAC;
    SSLerr(SSL_F_SSL3_GET_RECORD,
           SSL_R_DECRYPTION_FAILED_OR_BAD_RECORD_MAC);
    goto f_err;
}

Vielleicht möchten Sie Ihre Cipher Suite neu anordnen:

SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SSLv3:!SSLv2:!TLSv1

Dieser Beitrag auf askubuntu über die POODLE-Sicherheitsanfälligkeit enthält eine hervorragende Liste von Ressourcen für die SSL-Überprüfung und die Installation.

Der Mozilla-Konfigurationsgenerator ist ein ausgezeichneter öffentlicher Dienst.

Der Kommentar "Diesen Fehler bei jedem fünften Klick erhalten" ist etwas seltsam. Meinen Sie Klicks oder jede fünfte Zeile ist eine schlechte Anfrage in den Protokollen? Versuchen Sie, Apache Single-Threaded (das -X-Flag) zu starten, und prüfen Sie, ob dies dasselbe bewirkt ... oder möglicherweise eine Einstellung SSLSessionTickets off.

Ich denke hier daran, Threading und Kohärenz / Konsistenz von Sitzung / Cache als Ursache für Probleme zu beseitigen. Das Ausführen von Apache Single-Threaded (Start mit dem Flag -X) ist eine Möglichkeit, dies zu erreichen, eine andere Möglichkeit, dies festzulegen MaxClients=1(zumindest mit dem MPM-Modell). Sitzungstickets waren in der Vergangenheit eine Problemquelle für TLSv1.2 und sind standardmäßig aktiviert. Dies ist der Grund dafür SSLSessionTickets off(beachten Sie, dass dies Teil der SSL-Nachricht "Server Hello" ist, kein Sitzungscookie oder ähnliches). Der Fehler "Jeder fünfte Klick" stört mich immer noch - ich kann nicht anders, als zu bemerken, dass die meisten Browser vier Ressourcenanforderungen in einer einzigen Pipeline weiterleiten ...) und eine neue Verbindung öffnen (ein neuer SSL-Handshake usw.) Zum fünften ... ohne Paketerfassung ist es schwer zu sagen, was tatsächlich los ist.

Es scheint, dass Sie die Verschlüsselungsverhandlung als Fehlerquelle eliminiert haben (Sie können die Fehlerbedingung unter viel restriktiveren Verschlüsselungsspezifikationen duplizieren, es sei denn, ich irre mich). Ich wäre gespannt, ob Sie den Fehler auslösen können, indem Sie SSL neu aushandeln (z. B. nur für Kicks). Geben Sie openssl s_client -connect server:443dann 'R' ein und sehen Sie, was in den Protokollen steht. Überprüfen Sie
auch, ob das Zwischenspeichern -reconnectvon Sitzungen mit der Option s_client funktioniert.
Bei den Empfangskontexten für die SSL-Anforderungen muss etwas anders sein, und es scheint der beste Weg zu sein, dies herauszufinden (abgesehen von einer byteweisen Überprüfung der Vorgänge über das Kabel, die möglicherweise schwer zu anonymisieren sind), zu streng Begrenzen Sie die Größe des Hörens (dh die Anzahl der Hörer).

Andere Debugging-Tools, die ich ausprobieren würde (vorausgesetzt, das Veröffentlichen von Paketerfassungen kommt nicht in Frage ...)
- ssltap ( libnss3-toolsauf Ubuntu)
- cipherscan
- sslscan

UPDATE Das
Stöbern in ssltap ähnelt sehr dem wieder aufgetauchten OpenSSL-Fehler Nr. 3712 (Schlüssel-Neuverhandlung beim Lesen / Schreiben im Grunde). Suchen Sie nach einer anständigen Problemumgehung, die die Leistung nicht beeinträchtigt. Lustige Sachen!

Ich habe das schon einmal gesehen, hatte das schon einmal.

Die Antwort in meinem Fall war äußerst subtil.

Der Netzwerkadapter aktivierte das TCP-Segment-Offloading, das aufgrund eines Fehlers in irgendeiner Form die letzten Bytes einiger Nachrichten entstellte (oder abschneidet, ich kann mich nicht erinnern), was anschließend dazu führte, dass der MAC in den SSL-Datensätzen fehlschlug.

Es war eine virtuelle Maschine unter VMWare.

Ich würde versuchen, TSO / GSO / GRO in Ihrer Umgebung zu deaktivieren und zu prüfen, ob das Problem behoben ist.

ethtool -K eth0 tso off gro off gso off ufo off

OpenSSL und Multithreading sind etwas seltsam. Welches MPM verwenden Sie? Wenn dies mit Multithreading zusammenhängt, sollte die "Vorgabel" sicher sein, während "Arbeiter" und "Ereignis" betroffen sein könnten.

Wenn Ihr Lastprofil dies zulässt, können Sie möglicherweise versuchen, auf Prefork umzuschalten und festzustellen, ob das Problem weiterhin besteht.

Stellen Sie zunächst sicher, dass Chrome aktualisiert ist. Ältere Versionen verursachen Probleme mit bestimmten Chiffren. Hatte dieses Problem mit Chrom selbst mit gängigen Websites wie Amazon usw.

Zweitens ist der Ratschlag, Protokolle in der von Ihnen befolgten "Verschlüsselungsliste" zu verbieten, eine sehr schlechte Idee, da er keine Protokolle verbietet. Er verbietet die meisten Chiffren, einschließlich derjenigen, die "seit" SSLv3 funktionieren (bedeutet jedoch nicht, dass Sie SSL3 aktivieren, wenn Sie erlauben SSLv3-Chiffren), verwenden aus Gründen der Kompatibilität eine allgemeinere Liste, die vom Mozilla SSL-Konfigurationsgenerator bereitgestellt wird (Hinweis: SSLv2 ist nicht mehr vorhanden oder wird in httpd oder openssl unterstützt, sodass kein Grund mehr besteht, es explizit zu verbieten), und möglicherweise war Ihre vorherige Kombination zu streng , Probier diese:

SSLProtocol             all -SSLv3
SSLCipherSuite          ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS

Wenn Sie immer noch Probleme haben, aktivieren Sie das Debuggen für SSL und sehen Sie, was httpd zu sagen hat (senden Sie nur ein oder zwei Versuche und deaktivieren Sie diese Protokollierung, dies ist zu laut):

LogLevel ssl:trace3

Nebenbemerkungen: Sie können auch SSLCertificateChainFile entfernen, da diese Anweisung in 2.4 veraltet ist. Sie können der Kette die SSLCertificateFile hinzufügen und alle Zertifikate von Blatt zu Stamm sortieren oder sogar SSLCertificateChainFile in SSLCACertificateFile ändern (obwohl diese hauptsächlich für die SSL-Authentifizierung verwendet wird).

Sie sollten auch hinzufügen (falls Sie dies noch nicht getan haben), um Folgendes hinzuzufügen:

SSLRandomSeed startup file:/dev/urandom 2048
SSLRandomSeed connect file:/dev/urandom 2048
SSLSessionCache shmcb:/path/to/log/ssl_gcache_data(512000)

Bearbeiten: Nach unserem Gespräch überprüfen wir die openssl-Installation und / oder ob es sich wirklich um dieselbe Version handelt, die Ihr httpd verwendet:

Geben Sie diesen Befehl ein und lassen Sie uns sehen, was darin steht: openssl ciphers -v 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS'

Um sicherzustellen, dass die openssl-Version die richtige ist, führen Sie Folgendes aus:

openssl version