SSL-Fehler bei E-Mails nach Update auf 2.4.0.beta4

Unterstützung Installation
1

Seit dem Upgrade auf 2.4.0.beta4 können keine meiner Installationen, die Rackspace für den ausgehenden E-Mail-Versand nutzen, E-Mails mehr versenden. Da der ausgehende E-Mail-Server erneut Rackspace ist, gehe ich davon aus, dass deren SSL/TLS-Einstellungen korrekt sind (und sie funktionieren ohnehin in allen gängigen E-Mail-Clients). Vielleicht hängt dies mit diesem Thread zusammen.

Nachdem kürzlich Updates angewendet wurden (ich bin mir nicht sicher, welche Änderung genau), lautet der Fehler jedoch nicht mehr wie im oben genannten Thread erwähnt, sondern ist nun folgender:

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

Ich vermute, dass dies ein Fehler ist.

Edit: Ein weiterer verwandter Thread

@Gerhard

2

Können Sie versuchen, aus dem Docker-Container eine Verbindung zum SMTP-Server herzustellen?

SMTP mit StartTLS (Standard, sofern Sie DISCOURSE_SMTP_ENABLE_START_TLS in app.yml nicht geändert haben):

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

SMTP

openssl s_client -connect <hostname>:<port>
3

Mit dem Flag -starttls gibt es einfach “CONNECTED” zurück. Ohne -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:
---
Zertifikatskette
 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
---
Serverzertifikat
-----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

---
Keine Client-Zertifikat-CA-Namen gesendet
---
SSL-Handshake hat 6414 Bytes gelesen und 319 Bytes geschrieben
Verifizierung: OK
---
Neu, (NONE), Cipher ist (NONE)
Server-öffentlicher Schlüssel ist 2048 Bit
Sichere Neuverhandlung wird unterstützt
Komprimierung: NONE
Expansion: NONE
Kein ALPN verhandelt
SSL-Sitzung:
    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
---
4

Es scheint, als sei das Problem erneut aufgetreten:

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

(Zumindest bei den letzten paar tausend Fehlversuchen.)

Auch: Alles Gute zum Geburtstag, @gerhard.

5

Dieser Fehler deutet darauf hin, dass der SMTP-Server falsch konfiguriert ist und einen DH-Schlüssel verwendet, den OpenSSL als zu klein einstuft.

6

Das erscheint von Rackspace etwas unwahrscheinlich, aber ich kann versuchen, einen ihrer Techniker dafür zu gewinnen.

7

Nun, der Fehler stammt von OpenSSL und soweit ich weiß nutzen wir die Standardwerte von Debian / Ruby? :man_shrugging:

8

Es scheint, als würde die neue Version des Basis-Images eine OpenSSL-Version enthalten, die endlich alte, unsichere Signaturalgorithmen verwirft.

Unsere Firmen-Intranet verfügt über eine alte Windows-Zertifizierungsstelle, die MD5 verwendet, was nach dem Upgrade die HTTPS-Funktionalität meiner Discourse-Installation vollständig unterbrochen hat. Nginx beschwerte sich über „SSL_CTX_use_certificate:ca md too weak

9

Das ist eine Frage an @gerhard

10

Ich bin mir ziemlich sicher, dass dies ein Fehler ist. Ich habe einen Techniker von Rackspace damit befasst, und er hat folgende Informationen zu deren DH-Schlüssel bereitgestellt:

Hier sind die öffentlich verfügbaren Informationen:

CA = Comodo Limited CA
Schlüssellänge des Zertifikats = 2048 Bit
Domänenname = mx1.emailsrvr.com und mx2.emailsrvr.com
Hostname des E-Mail-Servers = secure.emailsrvr.com
Mail-Host-Software (Identifizieren Sie die Software und die auf dem MTA laufende Version) =
ecelerity 2.2.3.49
Verschlüsselungsstärke = AES256-SHA

Ich würde sagen, ein 2048-Bit-Schlüssel kann nicht (zutreffend) als „zu klein“ betrachtet werden.

11

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

Die derzeit empfohlene Mindestgröße für DH-Parameter beträgt 2048 Bit. Alles, was 1024 Bit entspricht oder darunter liegt, gilt als unsicher.

Okay, werfen wir uns also einen DH-Schlüssel an, indem wir eine ältere Version von Debian verwenden:

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

Ja, der DH-Schlüssel ist definitiv zu klein:

Server Temp Key: DH, 1024 bits

Ich würde sagen, das ist etwas, das Rackspace beheben sollte. Als Workaround sollten Sie in der Lage sein, /etc/ssl/openssl.cnf zu bearbeiten und CipherString = DEFAULT@SECLEVEL=2 am Ende der Datei zu entfernen. Sidekiq sollte die neuen OpenSSL-Einstellungen nach dem Neustart des Containers übernehmen.

12 
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

Zurück zum Chat mit Rackspace.

16

Update von Rackspace:

Vielen Dank für Ihre Geduld und dafür, dass Sie uns darauf aufmerksam gemacht haben. Wir können bestätigen, dass unser aktueller DH-Schlüssel 1024 Bit beträgt. Unsere Produkt- und Engineering-Teams haben anerkannt, dass dieser Wert erhöht werden muss, und haben bereits Pläne zur Behebung dieses Problems.

Ich kann Ihnen noch kein genaues Datum für die Umsetzung der Korrektur nennen, wobei das Ziel ist, dies noch diesen Monat zu erledigen. Sobald wir die DH-Schlüsselgröße erhöht haben, werden wir Sie umgehend auf dem Laufenden halten.

Nochmals vielen Dank, dass Sie uns darauf aufmerksam gemacht haben! Falls Sie weitere Fragen oder Bedenken haben, teilen Sie uns dies bitte mit!

Ich werde diesen Thread aktualisieren, sobald ich die Benachrichtigung erhalte, dass der DH-Schlüssel aktualisiert wurde.

17

Ich konnte mein Problem mit diesem Patch zwar beheben, aber das sieht nicht sehr vielversprechend aus :slight_smile:
Beim nächsten Neuaufbau wird es wieder weg sein, oder? :slight_smile:

18

Nun, hoffentlich wird Rackspace das Problem beheben, bevor du einen Neuaufbau durchführen musst. Andernfalls kannst du openssl.cnf innerhalb von app.yml mithilfe von sed-Befehlen ändern, um die Änderung dauerhaft zu machen.

19

Update von Rackspace:

Vielen Dank für Ihre Geduld. Die DH-Schlüsselgröße wurde aktualisiert und entspricht nun der Zertifikatsschlüsselgröße. Bitte testen Sie es und lassen Sie uns wissen, falls Sie weitere Fragen oder Bedenken haben!

Verifiziert:

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

Ich habe zudem weiter überprüft, dass ich wieder E-Mails von meinen Discourse-Installationen versenden kann. Das Problem ist also (zumindest für Rackspace) behoben.