Je reçois une erreur: SSL3_GET_RECORD: échec du déchiffrement ou mauvais enregistrement mac
J'ai mon propre serveur (où j'exécute Apache/2.4.27), et aujourd'hui j'ai réalisé que de (Brave et Google Chrome - ordinateurs différents) je reçois de mes sites Web cette erreur;
This site can’t provide a secure connection
mywebsite.com sent an invalid response.
ERR_SSL_PROTOCOL_ERROR
Et ce qui est étrange, c'est que j'obtiens cette erreur tous les cinq clics sur mon site Web.
De mon fichier conf:
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
de options-ssl-Apache.conf;
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLHonorCipherOrder on
SSLCompression off
J'ai vérifié le fichier journal du site Web mais rien, rien ici non plus; /var/log/Apache2/error.log
J'essaie de comprendre ce qui cause cette erreur, des idées où puis-je trouver plus d'informations ou encore mieux, comment résoudre ce problème?
MODIFIER:
Si j'essaie openssl s_client -connect mywebsite.com:443, il renverra:
J'utilise: 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:
NE AUTRE MODIFICATION:
Comme l'a suggéré @quadruplebucky, j'ai changé options-ssl-Apache.conf en:
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SSLv3:!SSLv2:!TLSv1
SSLHonorCipherOrder on
SSLCompression off
#SSLSessionTickets off
J'ai également essayé d'ajouter SSLProtocol all -SSLv2 -SSLv3 dans mon fichier virtualhost conf, et en même temps j'ai changé quelques choses ici; /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
MODIFIER:
Après avoir changé LogLevel en Info, il retourne:
[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)
MODIFIER:
Si je lance avec l'option -crlf, comme ceci:
openssl s_client -crlf -connect mywebsite:443
Je ne reçois aucune erreur?
Encore une chose si je change LogLevel pour déboguer, avant cette erreur, j'obtiens ceci:
[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()
Donc, après cette même erreur se produira:
SSL Library Error: error:140940F4:SSL routines:ssl3_read_bytes:unexpected message
openssl version
OpenSSL 1.1.0f 25 May 2017
Vous ne pouvez pas dire à partir de cette erreur si votre serveur négocie SSLv3 ou TLSv1 (vous voudrez peut-être jeter un œil à cette question sur Unix et Linux et vous assurer qu'il est désactivé partout dans Apache ...) --- le code source 1.1.0f ici sur GitHub brouille délibérément les deux ...
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;
}
Donc, vous voudrez peut-être réorganiser votre suite de chiffrement:
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SSLv3:!SSLv2:!TLSv1
Ce post sur askubuntu à propos de la vulnérabilité POODLE a une excellente liste de ressources pour l'inspection SSL et la plomberie.
Le générateur de configuration de Mozilla est un service public excellent.
Le commentaire "obtenir cette erreur tous les cinq clics" est un peu étrange. Voulez-vous dire clics, ou chaque cinquième ligne est une mauvaise demande dans les journaux? Essayez de démarrer Apache single-threaded (l'indicateur -X) et voyez si cela fait la même chose ... ou peut-être en définissant SSLSessionTickets off.
Ma pensée ici est d'éliminer le threading et la cohérence/cohérence session/cache comme source de problèmes. Exécuter Apache single-threaded (en commençant par l'indicateur -X) est une façon d'y parvenir, une autre façon est de définir MaxClients=1 (au moins avec le modèle MPM). Les tickets de session ont été une source de problèmes dans le passé avec TLSv1.2 et ils sont activés par défaut, c'est le raisonnement derrière SSLSessionTickets off (notez que cela fait partie du message SSL "Server Hello", pas un cookie de session ou similaire). L'erreur `` chaque cinquième clic '' me dérange toujours - je ne peux m'empêcher de remarquer que la plupart des navigateurs acheminent quatre demandes de ressources en une seule ...) et ouvrent une nouvelle connexion (une nouvelle poignée de main SSL, etc ...) pour le cinquième ... sans capture de paquets, il est difficile de dire ce qui se passe réellement.
Il semblerait que vous ayez éliminé la négociation de chiffrement comme source d'erreur (vous pouvez dupliquer la condition d'erreur sous des spécifications de chiffrement beaucoup plus restrictives, sauf erreur de ma part). Je serais curieux de savoir si vous pouvez déclencher l'erreur en renégociant SSL (juste pour les coups de pied, disons): openssl s_client -connect server:443 puis tapez 'R', voyez ce que disent les journaux.
Vérifiez également si la mise en cache de session fonctionne avec le -reconnect option pour s_client.
Quelque chose doit être différent sur les contextes de réception pour les requêtes SSL, et cela semble le meilleur moyen de le comprendre (à moins d'une inspection octet par octet de ce qui se passe sur le fil, qui peut être difficile à anonymiser) est de limiter sévèrement la taille de ce qui écoute (c'est-à-dire le nombre d'auditeurs).
D'autres outils de débogage que j'essaierais (en supposant que la publication de captures de paquets est hors de question ....)
- ssltap (dans libnss3-tools sur ubuntu)
- chiffrement
- sslscan
[~ # ~] mise à jour [~ # ~]
Pousser à travers ssltap ressemble énormément à bogue OpenSSL # 3712 refait surface (renégociation de clé pendant la lecture/écrire, essentiellement). Vous recherchez une solution de contournement décente qui ne réduira pas les performances. Truc amusant!
J'ai déjà vu ça, je l'ai déjà eu en fait.
La réponse dans mon cas a fini par être extrêmement subtile.
L'adaptateur réseau a activé TCP Segment Offloading, qui, en raison d'un bogue d'une certaine forme, gâchait (ou tronquait, je ne me souviens pas) les derniers octets de certains messages - ce qui provoquait par la suite le MAC sur l'échec des enregistrements SSL.
C'était une machine virtuelle sur VMWare.
J'essaierais de désactiver TSO/GSO/GRO dans votre environnement et de voir si le problème disparaît.
ethtool -K eth0 tso off gro off gso off ufo off
Il y a une certaine bizarrerie avec OpenSSL et le multithreading. Quel MPM utilisez-vous? Si cela est lié au multithreading, la "pré-fourche" devrait être sûre tandis que "travailleur" et "événement" pourraient être affectés.
Si votre profil de charge le permet, vous pouvez peut-être essayer de passer à prefork et voir si le problème persiste.
Assurez-vous d'abord que chrome est mis à jour. Les anciennes versions posent des problèmes avec certains chiffres. J'ai eu ce problème avec le chrome moi-même avec des sites courants comme Amazon, etc.
Deuxièmement, le conseil d'interdire les protocoles dans la "liste de chiffrement" que vous avez suivie est une très mauvaise idée car il n'interdira pas les protocoles, il interdira la plupart des chiffrements, y compris ceux qui fonctionnent "depuis" SSLv3 (mais ne signifie pas que vous activez SSL3 si vous autorisez les chiffrements SSLv3), utilisez une liste plus générique fournie par le générateur de configuration SSL de Mozilla pour la compatibilité (notez que SSLv2 n'existe plus ou est pris en charge dans httpd ou openssl, donc aucune raison de l'interdire explicitement) et peut-être que votre combinaison précédente était trop stricte , essaye celui-là:
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
Si vous avez toujours des problèmes, activez le débogage pour SSL et voyez ce que httpd a à dire (n'envoyez qu'un ou deux essais et désactivez cette journalisation, c'est trop bruyant):
LogLevel ssl:trace3
Sidenotes: Vous pouvez également aller de l'avant et supprimer SSLCertificateChainFile car cette directive est déconseillée en 2.4. Vous pouvez ajouter la chaîne SSLCertificateFile et trier tous les certificats de leaf à root, ou même changer SSLCertificateChainFile en SSLCACertificateFile (bien que celui-ci soit principalement utilisé pour l'authentification SSL).
Vous devez également ajouter (si vous ne l'avez pas encore fait) pour ajouter:
SSLRandomSeed startup file:/dev/urandom 2048
SSLRandomSeed connect file:/dev/urandom 2048
SSLSessionCache shmcb:/path/to/log/ssl_gcache_data(512000)
Edit: Après notre conversation, essayons de vérifier l'installation d'OpenSL et/ou s'il s'agit vraiment de la même version que votre httpd utilise:
Émettez cette commande et voyons ce qu'elle dit: 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'
Aussi pour vous assurer que la version openssl est la bonne, exécutez ceci:
openssl version