Erros de SSL no Email após atualização para 2.4.0.beta4

Desde a atualização para a versão 2.4.0.beta4, nenhuma das minhas instalações que utilizam o Rackspace para envio de e-mails conseguiu enviar e-mails de saída. Considerando que o servidor de e-mail de saída é, novamente, o Rackspace, presumo que as configurações SSL/TLS deles estejam corretas (e, de qualquer forma, elas parecem funcionar em todos os principais clientes de e-mail). Talvez este tópico esteja relacionado.

No entanto, após aplicar atualizações recentes (não tenho certeza de qual mudança exatamente), o erro não é mais o mesmo mencionado no tópico acima, mas sim este:

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

Presumo que isso seja um bug.

Edição: Outro tópico relacionado

@Gerhard

Você pode tentar conectar ao servidor SMTP de dentro do contêiner Docker?

SMTP com StartTLS (padrão, a menos que você tenha alterado DISCOURSE_SMTP_ENABLE_START_TLS em app.yml):

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

SMTP

openssl s_client -connect <hostname>:<port>

Com a flag -starttls, ele simplesmente retorna “CONNECTED”. Sem -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
---

Parece que o problema retornou:

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

(Pelo menos nas últimas milhares de falhas.)

Também: Feliz aniversário, @gerhard.

Esse erro sugere que o servidor SMTP está configurado incorretamente e utiliza uma chave DH que o OpenSSL considera muito pequena.

Isso parece um pouco improvável por parte da Rackspace, mas posso tentar envolver um de seus técnicos nisso.

Bem, o erro vem do OpenSSL e, até onde sei, estamos usando os padrões fornecidos pelo Debian/Ruby? :man_shrugging:

Parece que a nova versão da imagem base empacota uma versão do OpenSSL que finalmente desativou algoritmos de assinatura antigos e inseguros.

Nossa intranet corporativa possui uma CA Windows antiga que usava MD5, o que quebrou completamente o HTTPS na minha instalação do Discourse após a atualização. O Nginx reclamou de “SSL_CTX_use_certificate:ca md too weak” e se recusou a carregar o certificado HTTPS.

O RHEL e o CentOS possuem um mecanismo legado para reativá-los, mas não consegui encontrar uma configuração de compatibilidade semelhante no Debian/Ubuntu.

Tenho certeza de que mais pessoas vão se deparar com isso, dada a quantidade de certificados antigos e inseguros por aí, mas provavelmente não há muito a fazer além de substituir os certificados. Eu tentaria entrar em contato diretamente com a Rackspace sobre o problema de e-mail.

Esta é uma pergunta para @gerhard

Tenho quase certeza de que isso é um bug. Tive um técnico da Rackspace analisando o problema, e ele forneceu as seguintes informações sobre a chave DH deles:

Aqui estão as informações publicamente disponíveis:

CA = Comodo Limited CA
Tamanho da Chave do Certificado = 2048 bits
Nome de Domínio = mx1.emailsrvr.com e mx2.emailsrvr.com
Nome do Host do Servidor de Email = secure.emailsrvr.com
Software do Servidor de Mail (identifique o software e a versão em execução no MTA) =
ecelerity 2.2.3.49
Força da Criptografia = AES256-SHA

Acho que uma chave de 2048 bits não seria (corretamente) considerada “muito pequena”.

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

O tamanho mínimo recomendado atualmente para parâmetros DH é de 2048 bits. Qualquer valor igual ou inferior a 1024 é considerado inseguro.

Certo, vamos examinar a chave DH usando uma versão mais antiga do 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"

Sim, a chave DH é definitivamente pequena demais:

Server Temp Key: DH, 1024 bits

Eu diria que isso é algo para a Rackspace corrigir. Como solução alternativa, você deve poder editar /etc/ssl/openssl.cnf e remover a linha CipherString = DEFAULT@SECLEVEL=2 no final do arquivo. O Sidekiq deve aplicar as novas configurações do OpenSSL após reiniciar o container.

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

De volta à conversa com a Rackspace.

Atualização da Rackspace:

Agradecemos sua paciência e por trazer isso à nossa atenção. Podemos confirmar que nossa chave DH atual é de 1024 bits. Nossas equipes de Produto e Engenharia reconheceram que isso precisa ser aumentado e já têm planos em andamento para corrigir o problema.

Não tenho uma data exata para quando a correção será implementada, embora o objetivo seja dentro deste mês. Assim que aumentarmos o tamanho da chave DH, garantiremos que você seja atualizado.

Mais uma vez, obrigado por trazer isso à nossa atenção! Se você tiver mais perguntas ou preocupações, por favor, nos avise!

Atualizarei este tópico assim que receber a notificação de que a chave DH foi atualizada.

Consegui resolver meu problema com aquele patch, mas não é muito promissor :slight_smile:
Na próxima recompilação ele vai sumir de novo, certo? :slight_smile:

Bem, esperamos que o Rackspace resolva o problema antes que você precise fazer uma reconstrução. Caso contrário, você pode modificar o openssl.cnf dentro do app.yml usando comandos sed para tornar a alteração permanente.

Atualização da Rackspace:

Agradecemos sua paciência. O tamanho da chave DH foi atualizado e agora corresponde ao tamanho da chave do certificado. Por favor, teste e nos informe se tiver mais alguma dúvida ou preocupação!

Verificado:

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

Verifiquei ainda que consigo enviar e-mails novamente a partir das minhas instalações do Discourse. Portanto (pelo menos para a Rackspace), esse problema foi resolvido.