2.4.0.beta4 への更新後のメール SSL エラー

2.4.0.beta4 へのアップグレード以降、Rackspace を経由して送信メールを送信しているすべてのインストールで、送信メールの送信ができなくなっています。送信メールサーバーも再び Rackspace であるため、彼らの SSL/TLS 設定は正しいと推測します(いずれにせよ、主要なメールクライアントでは問題なく動作しています)。おそらく、このスレッド が関連しているかもしれません。

ただし、最近のアップデートを適用した後(どの変更が正確に原因かは不明ですが)、エラーは前述のスレッドで言及されていたものとは異なり、現在は以下のものになっています:

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

これはバグだと推測します。

編集:別の関連スレッド

@Gerhard

Docker コンテナ内から SMTP サーバーへの接続を試してみてください。

StartTLS を使用する SMTPapp.ymlDISCOURSE_SMTP_ENABLE_START_TLS を変更しない限り、これがデフォルトです):

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

SMTP

openssl s_client -connect <hostname>:<port>

-starttls フラグを使用すると、単に “CONNECTED” が返されます。-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:
---
Certificate chain
 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
---
Server certificate
-----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

---
No client certificate CA names sent
---
SSL handshake has read 6414 bytes and written 319 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    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
---

問題が再発しているようです:

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

(少なくとも過去数千回の失敗において。)

また、@gerhard さん、お誕生日おめでとうございます。

そのエラーは、SMTP サーバーの設定が不適切で、OpenSSL が小さすぎると判断する DH 鍵を使用していることを示しています。

Rackspaceからそのような対応がなされるとは少し考えにくいですが、技術者の一人をこの件に関わらせてみることはできます。

さて、このエラーは OpenSSL に由来するもので、私の知る限り、Debian / Ruby が提供するデフォルト設定を使用していますよね? :man_shrugging:

ベースイメージの新しいバージョンには、ついに古い安全でない署名アルゴリズムを廃止した OpenSSL のバージョンが含まれているようです。

当社のイントラネットには、MD5 を使用している古い Windows 認証局(CA)があり、アップグレード後に Discourse インストールの HTTPS が完全に機能しなくなりました。Nginx が「SSL_CTX_use_certificate:ca md too weak」と報告し、HTTPS 証明書の読み込みを拒否しました。

RHEL および CentOS には、これらを再度有効にするレガシーな仕組みがありますが、Debian/Ubuntu には同様の互換性設定が見つかりませんでした。

至る所に存在する古い安全でない証明書の数を考えると、より多くの人々がこの問題に直面するでしょうが、証明書の置き換えを行う以外に対処法はほとんどないと思われます。メールの問題については、Rackspace に直接連絡することをお勧めします。

これは @gerhard への質問です

これはバグである可能性が非常に高いです。Rackspaceの技術者が調査してくれ、以下のDHキーに関する情報を提供してくれました。

公開されている情報は以下の通りです:

CA = Comodo Limited CA
Certificate Key Size = 2048 bit
Domain Name = mx1.emailsrvr.com and mx2.emailsrvr.com
Email server hostname = secure.emailsrvr.com
Mail Host Software (Identify the software and version is running on the MTA) =
ecelerity 2.2.3.49
Cipher Strength = AES256-SHA

2048ビットのキーは「小さすぎる」とは正確には言えないはずです。

U.S. | Let There Be Change | Accenture より

現在推奨されている DH パラメータの最小サイズは 2048 ビットです。1024 ビット以下は安全ではないとみなされます。

では、古いバージョンの Debian を使用して DH キーを確認してみましょう。

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

はい、DH キーが明らかに小さすぎます。

Server Temp Key: DH, 1024 bits

これは Rackspace が修正すべき問題だと思います。応急処置として、/etc/ssl/openssl.cnf を編集し、ファイル末尾の CipherString = DEFAULT@SECLEVEL=2 を削除してください。コンテナを再起動すると、Sidekiq が新しい OpenSSL 設定を反映します。

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

Rackspace とのチャットに戻る。

Rackspaceからの更新:

ご忍耐いただき、またご指摘をいただきありがとうございます。現在の DH キーが 1024 ビットであることを確認しました。製品チームとエンジニアリングチームは、これを増やす必要があることを認識しており、修正のための計画を策定しています。

修正が適用される正確な日付については現時点でお伝えできませんが、目標は今月中となっています。DH キーのサイズを増やした際には、必ず更新情報をお届けいたします。

ご指摘をいただき改めてありがとうございます。追加のご質問やご懸念がございましたら、お気軽にお知らせください!

DH キーがアップグレードされたという通知を受け次第、このスレッドを更新いたします。

そのパッチで問題が解決できましたが、あまり期待できませんね :slight_smile: 次のビルドではまた消えてしまいますよね? :slight_smile:

まあ、Rackspace が再ビルドを行う前にこの問題を修正してくれることを願っています。そうでない場合は、app.yml 内で sed コマンドを使って openssl.cnf を修正し、永続的な変更として設定することもできます。

Rackspaceからの更新:

ご辛抱ありがとうございます。DHキーサイズが更新され、証明書キーサイズと一致するようになりました。テストを実施し、追加のご質問やご懸念がございましたらお知らせください!

確認済み:

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

さらに、Discourseのインストールからメールを送信できることを確認しました。したがって(少なくともRackspaceにおいては)、この問題は解決しています。