Erreurs SSL de l'email après la mise à jour vers 2.4.0.beta4

Depuis la mise à niveau vers la version 2.4.0.beta4, aucune de mes installations utilisant Rackspace pour l’envoi d’e-mails n’a pu envoyer de courriels sortants. Étant donné que le serveur d’envoi d’e-mails est, encore une fois, Rackspace, je suppose que leurs paramètres SSL/TLS sont corrects (et, de toute façon, ils semblent fonctionner dans tous les principaux clients de messagerie). Peut-être que ce fil de discussion est lié.

Cependant, après avoir appliqué les récentes mises à jour (je ne suis pas certain de la modification exacte), l’erreur n’est plus la même que celle mentionnée dans le fil de discussion susmentionné, mais est désormais la suivante :

Jobs::HandledExceptionWrapper: Wrapped Net::ReadTimeout: Net::ReadTimeout with #<TCPSocket:(closed)>

Je suppose qu’il s’agit d’un bogue.

Édition : Un autre fil de discussion lié

@Gerhard

Pouvez-vous essayer de vous connecter au serveur SMTP depuis le conteneur Docker ?

SMTP avec StartTLS (par défaut, sauf si vous avez modifié DISCOURSE_SMTP_ENABLE_START_TLS dans app.yml) :

openssl s_client -connect <hostname>:<port> -starttls smtp

SMTP

openssl s_client -connect <hostname>:<port>

Avec le drapeau -starttls, il retourne simplement “CONNECTED”. Sans -starttls :

root@omnifora-com-app:/var/www/discourse# openssl s_client -connect secure.emailsrvr.com:465
CONNECTED(00000003)
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
verify return:1
depth=0 OU = Domain Control Validated, OU = EssentialSSL, CN = secure.emailsrvr.com
verify return:1
139636332590208:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small:../ssl/statem/statem_clnt.c:2156:
---
Chaîne de certificats
 0 s:OU = Domain Control Validated, OU = EssentialSSL, CN = secure.emailsrvr.com
   i:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
 1 s:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
   i:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
 2 s:C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
   i:C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
 3 s:C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
   i:C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
---
Certificat du serveur
-----BEGIN CERTIFICATE-----
MIIG5jCCBc6gAwIBAgIRAMWoQ0lmf1VC8Ch8zZZTHm0wDQYJKoZIhvcNAQELBQAw
gZAxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTYwNAYD
VQQDEy1DT01PRE8gUlNBIERvbWFpbiBWYWxpZGF0aW9uIFNlY3VyZSBTZXJ2ZXIg
Q0EwHhcNMTkwMTEwMDAwMDAwWhcNMjAwMzEwMjM1OTU5WjBZMSEwHwYDVQQLExhE
b21haW4gQ29udHJvbCBWYWxpZGF0ZWQxFTATBgNVBAsTDEVzc2VudGlhbFNTTDEd
MBsGA1UEAxMUc2VjdXJlLmVtYWlsc3J2ci5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDZzFpkI/ujPCuNZpHLueu+/iqUsc5U7+yYa9d6xIbkh2BN
u+OpBNCTn4ACa0a3EaqRVyceUUh8TodUPtkZYLZO6iqwl2eOd8h3NXxtRlyaj0Hz
uSOlRbA5CiVZ4H1Ia8k/DVh+r1Rk6Da/f52wBJE8ICFgm7Uyrjtfcc90gBk+7i4I
y1aNwKW/nqmqQBEiTeyUF2kJiTovtorQo7zaedPefm2VUoKyxe/8jl7qA7F9+1p0
XvvWrc3/vqEEZR6tmcAF8tmp0MSkMnt3klwg/xopVn5nPq52t6fLRXA0aLFBUHzT
U82Iw1Weg+gUVi77ONDIabfYuCqqEgpnAyeUhh8hAgMBAAGjggNvMIIDazAfBgNV
HSMEGDAWgBSQr2o6lFoL2JDqElZz30O0Oija5zAdBgNVHQ4EFgQUFJzBKVTbToPC
UoxWxXfRAJGz+YswDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0l
BBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCME8GA1UdIARIMEYwOgYLKwYBBAGyMQEC
AgcwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLmNvbS9DUFMw
CAYGZ4EMAQIBMFQGA1UdHwRNMEswSaBHoEWGQ2h0dHA6Ly9jcmwuY29tb2RvY2Eu
Y29tL0NPTU9ET1JTQURvbWFpblZhbGlkYXRpb25TZWN1cmVTZXJ2ZXJDQS5jcmww
gYUGCCsGAQUFBwEBBHkwdzBPBggrBgEFBQcwAoZDaHR0cDovL2NydC5jb21vZG9j
YS5jb20vQ09NT0RPUlNBRG9tYWluVmFsaWRhdGlvblNlY3VyZVNlcnZlckNBLmNy
dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMDkGA1UdEQQy
MDCCFHNlY3VyZS5lbWFpbHNydnIuY29tghh3d3cuc2VjdXJlLmVtYWlsc3J2ci5j
b20wggGABgorBgEEAdZ5AgQCBIIBcASCAWwBagB3ALvZ37wfinG1k5Qjl6qSe0c4
V5UKq1LoGpCWZDaOHtGFAAABaDf6Nt0AAAQDAEgwRgIhAJDqOzt2LWqviVrjKGFL
UCPuu/HWeuILG/7VuDwJWWYYAiEAvCaXH3lSCRWOgGquaz9lW3uITCuKQP0TOOMv
JPbcN/IAdwBep3P531bA57U2SH3QSeAyepGaDIShEhKEGHWWgXFFWAAAAWg3+jcn
AAAEAwBIMEYCIQCxU8IX94IoSwsrpo6zJoUMO4uNGuTkpLSY0h/KWbspqQIhAIy4
XfY5RtTTLpB3EFLXMyQSL9/gyNpfJ1OtbYtOkL0pAHYA8JWkWfIA0YJAEC0vk4iO
rUv+HUfjmeHQNKawqKqOsnMAAAFoN/o5AAAABAMARzBFAiAePxbn6JuVUkYjBVnF
MPHeqyqAaYpdwyGxaC3Cz4WZhAIhAPFXU3e0+7GkNMjXFPQ6UMd55zeUJcxakFIt
ggm7ioLYMA0GCSqGSIb3DQEBCwUAA4IBAQAkLuNWuHt5GOXkzJlys09mg22+MnhF
4y+abm7F54stsv0A2Gc4my4bEXOZ4ozf0g1Yjb/ZVlSVrNC125CSnXd6bEcesjcn
c3oxO+9dFCQGMH4CZPVSoDKBk41+VP9IcnfibhSzV8wFXQh+Tt1OpRoNgqM888Es
JvYP9B2OgDvQFnDNAcJXM5fgX1CilyXqPtz2QYDNVgN8tuRSRPlaGTkZgGMsCO12
GjxLD5UGsxh5c08KSRgd4Uv6BRH/hE62spqvmDUDzuU+Qx9N4/Tz2ocv8LI8GlqV
RYOe+6lLe8t33yH0dnRWKGrpT8gWkul1qLHI9I7LYZMvMKdcxl8oBBGF
-----END CERTIFICATE-----
subject=OU = Domain Control Validated, OU = EssentialSSL, CN = secure.emailsrvr.com

issuer=C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA

---
Aucun nom d'AC de certificat client envoyé
---
La poignée de main SSL a lu 6414 octets et écrit 319 octets
Vérification : OK
---
Nouveau, (NONE), le chiffrement est (NONE)
La clé publique du serveur fait 2048 bits
La renégociation sécurisée EST prise en charge
Compression : AUCUNE
Expansion : AUCUNE
Aucune négociation ALPN
Session SSL :
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1569003408
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---

Il semble que le problème soit revenu :

Jobs::HandledExceptionWrapper: Wrapped OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=error: dh key too small

(En tout cas pour les milliers d’échecs récents.)

Aussi : Joyeux anniversaire, @gerhard.

Cette erreur suggère que le serveur SMTP est mal configuré et utilise une clé DH jugée trop petite par OpenSSL.

Cela semble peu probable de la part de Rackspace, mais je peux essayer d’impliquer l’un de leurs techniciens dans cette affaire.

Eh bien, l’erreur provient d’OpenSSL et, à ma connaissance, nous utilisons les paramètres par défaut fournis par Debian / Ruby ? :man_shrugging:

Il semble que la nouvelle version de l’image de base inclue une version d’OpenSSL qui a enfin désactivé les anciens algorithmes de signature non sécurisés.

Notre intranet d’entreprise utilise un ancien CA Windows qui employait MD5, ce qui a complètement rompu HTTPS sur mon installation Discourse après la mise à niveau. Nginx a signalé l’erreur « SSL_CTX_use_certificate:ca md too weak » et a refusé de charger le certificat HTTPS.

RHEL et CentOS disposent d’un mécanisme hérité pour les réactiver, mais je n’ai pas trouvé de paramètre de compatibilité similaire dans Debian/Ubuntu.

Je suis certain que beaucoup d’autres personnes vont rencontrer ce problème étant donné le nombre de vieux certificats non sécurisés en circulation, mais il n’y a probablement pas grand-chose à faire d’autre que de remplacer ces certificats. Je vous suggère de contacter directement Rackspace concernant le problème de messagerie.

Ceci est une question pour @gerhard

Je suis presque certain qu’il s’agit d’un bug. J’ai demandé à un technicien de Rackspace d’examiner le problème, et il m’a fourni les informations suivantes concernant leur clé DH :

Voici les informations publiquement disponibles :

CA = Comodo Limited CA
Taille de la clé du certificat = 2048 bits
Nom de domaine = mx1.emailsrvr.com et mx2.emailsrvr.com
Nom d'hôte du serveur de messagerie = secure.emailsrvr.com
Logiciel hôte de messagerie (identifiez le logiciel et la version en cours d'exécution sur le MTA) =
ecelerity 2.2.3.49
Force du chiffrement = AES256-SHA

Je pense qu’une clé de 2048 bits ne devrait pas (exactement) être considérée comme « trop petite ».

Depuis U.S. | Let There Be Change | Accenture

La taille minimale recommandée actuellement pour les paramètres DH est de 2048 bits. Toute valeur égale ou inférieure à 1024 est considérée comme non sécurisée.

D’accord, examinons donc la clé DH en utilisant une ancienne version de Debian :

docker run --rm -it debian:stretch
apt update && apt install -y openssl
openssl s_client -connect secure.emailsrvr.com:465 | grep "Server Temp Key"

Oui, la clé DH est clairement trop petite :

Server Temp Key: DH, 1024 bits

Je dirais que c’est à Rackspace de corriger cela. En attendant, vous devriez pouvoir modifier /etc/ssl/openssl.cnf et supprimer CipherString = DEFAULT@SECLEVEL=2 à la fin du fichier. Sidekiq devrait prendre en compte les nouveaux paramètres OpenSSL après le redémarrage du conteneur.

openssl s_client -connect secure.emailsrvr.com:465 | grep "Server Temp Key"
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
verify return:1
depth=0 OU = Domain Control Validated, OU = EssentialSSL, CN = secure.emailsrvr.com
verify return:1
Server Temp Key: DH, 1024 bits

Retour à la discussion avec Rackspace.

Mise à jour de Rackspace :

Merci pour votre patience et merci d’avoir attiré notre attention sur ce point. Nous pouvons confirmer que notre clé DH actuelle fait 1024 bits. Nos équipes Produit et Ingénierie ont reconnu que cela doit être augmenté et ont mis en place un plan pour résoudre ce problème.

Je ne peux pas vous donner de date exacte pour le déploiement de la correction, bien que l’objectif soit de le faire au cours de ce mois-ci. Dès que nous aurons augmenté la taille de la clé DH, nous ne manquerons pas de vous tenir informé.

Encore merci d’avoir signalé cela ! Si vous avez d’autres questions ou préoccupations, n’hésitez pas à nous le faire savoir !

Je mettrai à jour ce fil de discussion dès que je recevrai la notification que la clé DH a été mise à niveau.

J’ai pu résoudre mon problème avec ce correctif, mais ce n’est pas très prometteur :slight_smile:
Il disparaîtra à nouveau lors de la prochaine reconstruction, n’est-ce pas ? :slight_smile:

Eh bien, espérons que Rackspace corrigera le problème avant que vous ayez besoin de procéder à une reconstruction. Sinon, vous pouvez modifier openssl.cnf depuis app.yml en utilisant des commandes sed pour rendre le changement permanent.

Mise à jour de Rackspace :

Merci pour votre patience. La taille de la clé DH a été mise à jour et correspond désormais à la taille de la clé du certificat. Veuillez effectuer des tests et nous faire part de toute question ou préoccupation supplémentaire !

Vérifié :

openssl s_client -connect secure.emailsrvr.com:465 | grep "Server Temp Key"
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Domain Validation Secure Server CA
verify return:1
depth=0 OU = Domain Control Validated, OU = EssentialSSL, CN = secure.emailsrvr.com
verify return:1
Server Temp Key: DH, 2048 bits

J’ai également vérifié que je pouvais à nouveau envoyer des e-mails depuis mes installations Discourse. Ainsi (du moins pour Rackspace), ce problème est résolu.