Postfix 2.6.6 com TLS - incapaz de receber e-mails do GMail (e alguns outros MTAs), mas outros estão OK, por quê?

Question

Eu só tive que olhar para um servidor CentOS 6 executando o Postfix 2.6.6, que era capaz de enviar e-mails para todos, mas não podia recebê-los do Gmail (e alguns outros MTAs) devido a problemas de negociação TLS.

Uma conexão de um servidor SMTP .google.com (isto é, GMail) resultou nisso:

Aug 23 19:34:29 server1 postfix/smtpd[7659]: connect from mail-lf1-f44.google.com[209.85.167.44]
Aug 23 19:34:29 server1 postfix/smtpd[7659]: setting up TLS connection from mail-lf1-f44.google.com[209.85.167.44]
Aug 23 19:34:29 server1 postfix/smtpd[7659]: SSL_accept error from mail-lf1-f44.google.com[209.85.167.44]: -1
Aug 23 19:34:29 server1 postfix/smtpd[7659]: warning: TLS library problem: 7659:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1387:
Aug 23 19:34:29 server1 postfix/smtpd[7659]: lost connection after STARTTLS from mail-lf1-f44.google.com[209.85.167.44]
Aug 23 19:34:29 server1 postfix/smtpd[7659]: disconnect from mail-lf1-f44.google.com[209.85.167.44]

Aumentando o detalhamento do registro de TLS:

Aug 23 21:56:15 server1 postfix/smtpd[18103]: initializing the server-side TLS engine
Aug 23 21:56:15 server1 postfix/smtpd[18103]: connect from mail-lf1-f47.google.com[209.85.167.47]
Aug 23 21:56:15 server1 postfix/smtpd[18103]: setting up TLS connection from mail-lf1-f47.google.com[209.85.167.47]
Aug 23 21:56:15 server1 postfix/smtpd[18103]: mail-lf1-f47.google.com[209.85.167.47]: TLS cipher list "ALL:+RC4:@STRENGTH:!aNULL:!LOW:!EXP:!MEDIUM:!ADH:!AECDH:!MD5:!DSS:!ECDSA:!CAMELLIA128:!3DES:!CAMELLIA256:!RSA+AES:!eNULL"
Aug 23 21:56:15 server1 postfix/smtpd[18103]: SSL_accept:before/accept initialization
Aug 23 21:56:15 server1 postfix/smtpd[18103]: SSL3 alert write:fatal:handshake failure
Aug 23 21:56:15 server1 postfix/smtpd[18103]: SSL_accept:error in SSLv3 read client hello C
Aug 23 21:56:15 server1 postfix/smtpd[18103]: SSL_accept error from mail-lf1-f47.google.com[209.85.167.47]: -1
Aug 23 21:56:15 server1 postfix/smtpd[18103]: warning: TLS library problem: 18103:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1387:
Aug 23 21:56:15 server1 postfix/smtpd[18103]: lost connection after STARTTLS from mail-lf1-f47.google.com[209.85.167.47]
Aug 23 21:56:15 server1 postfix/smtpd[18103]: disconnect from mail-lf1-f47.google.com[209.85.167.47]

Nenhuma cifra compartilhada?!

O TLS já estava ativado com um certificado de servidor (embora auto-assinado); clientes estavam se conectando com sucesso para enviar e receber e-mails através de IMAP / POP com SASL.

Eu li as causas comuns do erro 1408A0C1 postfix, mas nenhum pareceu se aplicar a esse cenário. Alguns dos testes que eu fiz produziram resultados que pareciam contradizer o que eu esperava;

postconf -d | grep cipherlist teve esta lista bastante pequena de exclusões:

tls_export_cipherlist = ALL:+RC4:@STRENGTH
tls_high_cipherlist = ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH
tls_low_cipherlist = ALL:!EXPORT:+RC4:@STRENGTH
tls_medium_cipherlist = ALL:!EXPORT:!LOW:+RC4:@STRENGTH
tls_null_cipherlist = eNULL:!aNULL

Os protocolos

e TLS foram bastante brandos:

smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtp_tls_mandatory_protocols  = !SSLv2, !SSLv3
smtpd_tls_protocols           = !SSLv2, !SSLv3
smtp_tls_protocols            = !SSLv2, !SSLv3

Então, por que não foi possível negociar uma cifra?

Primeiramente, comecei a atualizar o OpenSSL (que era OpenSSL 1.0.1e-fips 11 Feb 2013 , o último disponível via yum ); Eu fiz conforme as instruções neste artigo e, consequentemente, a caixa é executada em OpenSSL 1.0.2p 14 Aug 2018 .

Mas ainda assim, o problema de recepção do GMail continuou ...

Eu deixei aqueles como estão para dar a todas as possíveis variantes de TLS uma chance de sucesso, e estudei as cifras em mais detalhes.

Desativando todas as exclusões de criptografia, enviei um e-mail de teste do meu Gmail e, sem surpresa, ele veio por meio de:

Aug 23 23:39:52 server1 postfix/smtpd[6036]: connect from mail-lj1-f171.google.com[209.85.208.171]
Aug 23 23:39:52 server1 postfix/smtpd[6036]: setting up TLS connection from mail-lj1-f171.google.com[209.85.208.171]
Aug 23 23:39:52 server1 postfix/smtpd[6036]: mail-lj1-f171.google.com[209.85.208.171]: TLS cipher list "ALL:+RC4:@STRENGTH"
Aug 23 23:39:52 server1 postfix/smtpd[6036]: SSL_accept:before/accept initialization
Aug 23 23:39:52 server1 postfix/smtpd[6036]: SSL_accept:SSLv3 read client hello B
Aug 23 23:39:52 server1 postfix/smtpd[6036]: SSL_accept:SSLv3 write server hello A
Aug 23 23:39:52 server1 postfix/smtpd[6036]: SSL_accept:SSLv3 write certificate A
Aug 23 23:39:52 server1 postfix/smtpd[6036]: SSL_accept:SSLv3 write server done A
Aug 23 23:39:52 server1 postfix/smtpd[6036]: SSL_accept:SSLv3 flush data
Aug 23 23:39:52 server1 postfix/smtpd[6036]: SSL_accept:SSLv3 read client key exchange A
Aug 23 23:39:52 server1 postfix/smtpd[6036]: SSL_accept:SSLv3 read finished A
Aug 23 23:39:52 server1 postfix/smtpd[6036]: SSL_accept:SSLv3 write session ticket A
Aug 23 23:39:52 server1 postfix/smtpd[6036]: SSL_accept:SSLv3 write change cipher spec A
Aug 23 23:39:52 server1 postfix/smtpd[6036]: SSL_accept:SSLv3 write finished A
Aug 23 23:39:52 server1 postfix/smtpd[6036]: SSL_accept:SSLv3 flush data
Aug 23 23:39:52 server1 postfix/smtpd[6036]: Anonymous TLS connection established from mail-lj1-f171.google.com[209.85.208.171]: TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)
Aug 23 23:39:52 server1 postfix/smtpd[6036]: 66BB15DC6: client=mail-lj1-f171.google.com[209.85.208.171]
Aug 23 23:39:52 server1 postfix/cleanup[6424]: 66BB15DC6: message-id=<CAK9Gk9r+6gt7g_U987A0XaGdKJGY=[e-mail]>
Aug 23 23:39:52 server1 opendkim[6890]: 66BB15DC6: mail-lj1-f171.google.com [209.85.208.171] not internal
Aug 23 23:39:52 server1 opendkim[6890]: 66BB15DC6: not authenticated
Aug 23 23:39:52 server1 opendkim[6890]: 66BB15DC6: DKIM verification successful
Aug 23 23:39:52 server1 postfix/qmgr[6032]: 66BB15DC6: from=<gmailaddress>, size=3988, nrcpt=1 (queue active)
Aug 23 23:39:52 server1 postfix/smtpd[6036]: disconnect from mail-lj1-f171.google.com[209.85.208.171]
Aug 23 23:39:52 server1 postfix/pipe[6425]: 66BB15DC6: to=<myinbox>, relay=dovecot, delay=0.48, delays=0.29/0.01/0/0.18, dsn=2.0.0, status=sent (delivered via dovecot service)

Então, se o GMail negociou AES128-GCM-SHA256 via TLSv1.2 - por que não estava funcionando antes? Particularmente, como sua lista de cifras parece ser qualquer correspondência possível, com RC4 no final, ordenada por ordem de força?

Para testar, peguei uma lista específica de cifras, prefixadas as profundidades de hash AES128 (em itálico) - métodos ECDHE e DHE - e explicitamente declarei no postfix, que funcionou:

tls_high_cipherlist=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA

No entanto, eu não queria atualizar constantemente as receitas da lista de códigos, por isso, comentei a declaração tls_high_cipherlist .

Eu então fiz algumas coisas.

No master.cf do postfix, adicionei -o smtp_tls_mandatory_protocols=TLSv1 à seção smtpd, conforme recomendado.

Eu queria melhorar os protocolos TLS usando declarações do link , que aprovam explicitamente o TLSv1. 2 e TLSv1.1 antes de excluir os mais antigos. No entanto, com o postfix 2.6.6, isso não funciona; Eu vi isso no log não muito tempo depois de um reload / restart:

warning: Invalid TLS protocol list "TLSv1.2, TLSv1.1, !TLSv1, !SSLv2, !SSLv3": disabling TLS support

Isso aconteceu se eu misturei as regras de exclusão com as regras de inclusão, então reverti para o formato de exclusão explícito:

smtpd_tls_protocols = !TLSv1, !SSLv2, !SSLv3
smtp_tls_protocols = !TLSv1, !SSLv2, !SSLv3
smtp_tls_ciphers = high
smtpd_tls_ciphers = high
smtpd_tls_mandatory_protocols = !TLSv1, !SSLv2, !SSLv3
smtp_tls_mandatory_protocols = !TLSv1, !SSLv2, !SSLv3
smtp_tls_mandatory_ciphers = high
smtpd_tls_mandatory_ciphers = high

e isso foi aceito pelo postfix.

Eu defino o TLS oportunista com

smtp_tls_security_level = may
smtpd_tls_security_level = may

Notei que, mesmo depois de resolver o problema de entrega do GMail, um punhado de outros MTAs ainda estava falhando:

server1 postfix/smtpd[28167]: connect from mta3.email.secretescapes.com[198.245.84.110]
server1 postfix/smtpd[28167]: setting up TLS connection from mta3.email.secretescapes.com[198.245.84.110]
server1 postfix/smtpd[28167]: mta3.email.secretescapes.com[198.245.84.110]: TLS cipher list "ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH:!MD5:!DES:!ADH:!RC4:!PSD:!SRP:!3DES:!eNULL:!aNULL"
server1 postfix/smtpd[28167]: SSL_accept:before/accept initialization
server1 postfix/smtpd[28167]: SSL_accept:error in SSLv2/v3 read client hello A
server1 postfix/smtpd[28167]: SSL_accept error from mta3.email.secretescapes.com[198.245.84.110]: -1
server1 postfix/smtpd[28167]: warning: TLS library problem: 28167:error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol:s23_srvr.c:647:
server1 postfix/smtpd[28167]: lost connection after STARTTLS from mta3.email.secretescapes.com[198.245.84.110]
server1 postfix/smtpd[28167]: disconnect from mta3.email.secretescapes.com[198.245.84.110]

-

server1 postfix/smtpd[1451]: initializing the server-side TLS engine
server1 postfix/smtpd[1451]: connect from mta.email.bbc.com[198.245.84.99]
server1 postfix/smtpd[1451]: setting up TLS connection from mta.email.bbc.com[198.245.84.99]
server1 postfix/smtpd[1451]: mta.email.bbc.com[198.245.84.99]: TLS cipher list "ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH:!MD5:!aDSS:!kECDH:!kDH:!SEED:!IDEA:!DES:!ADH:!RC2:!RC4:!RC5:!PSD:!SRP:!3DES:!eNULL:!aNULL"
server1 postfix/smtpd[1451]: SSL_accept:before/accept initialization
server1 postfix/smtpd[1451]: SSL_accept:error in SSLv2/v3 read client hello A
server1 postfix/smtpd[1451]: SSL_accept error from mta.email.bbc.com[198.245.84.99]: -1
server1 postfix/smtpd[1451]: warning: TLS library problem: 1451:error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol:s23_srvr.c:647:
server1 postfix/smtpd[1451]: lost connection after STARTTLS from mta.email.bbc.com[198.245.84.99]
server1 postfix/smtpd[1451]: disconnect from mta.email.bbc.com[198.245.84.99]
server1 postfix/smtpd[1451]: connect from unknown[107.174.30.57]
server1 postfix/smtpd[1451]: 4F6D0629C: client=unknown[107.174.30.57]

Eu então tentei algumas permutações da tls_high_cipherlist, antes de acabar usando a lista recomendada do bettercrypto.org :

tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA

O servidor foi testado com vários testadores de SSL, incluindo CheckTLS (resultado de 100%), Luxsci (resultado A +), testador SSL da htbridge (boa nota ) e SSL-Tools .

Estou ciente de que você pode mapear políticas de conexões de saída, mas eu estou procurando um equivalente para que eu possa desativar seletivamente quaisquer exclusões para determinados MTAs (conforme encontrá-los) e descobrir qual cifra eles estão negociando, em seguida, ajustar o lista de cifras que apresento.

Eu não consigo ver nenhuma falha massivamente óbvia na atual configuração de TLS do postfix. Não sei por que certos MTAs não podem negociar uma codificação TLS quando outros gerenciam bem. Mesmo o exigente, GMail, agora está bem.

Alguma idéia? : -)

Eu notei esta pergunta sobre o motivo pelo qual o Google prefere a cifra que faz , que fez uma leitura interessante.

Cortesia de este tópico do fórum de usuários do Postfix , I encontrou uma receita útil para ver rapidamente quantas conexões TLS foram feitas com sucesso em todas as cifras disponíveis:

egrep "TLS connection established from.*with cipher" /var/log/maillog* | awk '{printf("%s %s %s %s\n", $12, $13, $14, $15)}' | sort | uniq -c | sort -

    

Answer 1

Em última análise, este problema parece ser devido a alguns remetentes ainda serem capazes de negociar o SSLv3. Isso é uma coisa ruim, mas não receber e-mails também não é ótimo.

É tão simples quanto isso. Eu não estou feliz com isso, mas se o envio de MTAs se recusar a renegociar para TLS, e apenas eternamente repetir com SSLv3, não há muito que possamos fazer por agora.

Então, por enquanto, recorri a permitir que os e-mails recebidos fossem criptografados com o SSLv3, mas exigindo que todos os clientes no servidor ainda tivessem que se autenticar via TLS.

Eu consegui isso facilitando os negadores de protocolo em main.cf :

smtpd_tls_mandatory_protocols = !TLSv1, !SSLv2
smtpd_tls_protocols = !TLSv1, !SSLv2

NB que as definições de smtp_tls_ são para e-mails enviados deste servidor, portanto, estejam relacionadas a conexões de clientes, para que você possa torná-las tão restritas quanto desejar (contanto que esteja disposto a explicar a todos como definir seus clientes de email):

smtp_tls_mandatory_protocols = !TLSv1, !SSLv2, !SSLv3
smtp_tls_protocols = !TLSv1, !SSLv2, !SSLv3

Se o envio de MTAs não for capaz de negociar o TLS, esperando SSLv3, é o que você normalmente verá no maillog:

warning: TLS library problem: 364:error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol:s23_srvr.c:647:

Se você discar o nível de registro, verá a negociação de TLS falhando, com mais mensagens como

postfix/smtpd[26234]: SSL_accept:before/accept initialization
postfix/smtpd[26234]: SSL_accept:error in SSLv2/v3 read client hello A
postfix/smtpd[26234]: SSL_accept error from 201-62-89-201.life.com.br[201.62.89.201]: -1

Eu tenho testado periodicamente desaprovando conexões SSLv3 (inevitavelmente os MTAs tentam novamente por muitos dias), então você pode permitir que algumas falhas ocorram nos logs e analisá-las.

Este script bash me ajuda a analisar quais servidores estão tentando usar o SSLv3:

#!/bin/sh
egrep "SSL_accept error" /var/log/maillog | awk '{printf("%s %s %s\n", $9, $10, $11)}' | sort | uniq -c | sort -'

E essa variação mostra cifras negociadas - assim, quando você reativar o SSLv3, pode deixar isso por um tempo e confirmar se os MTAs estão usando o SSLv3:

#!/bin/sh
egrep "TLS connection established from.*with cipher" /var/log/maillog | awk '{printf("%s %s %s %s\n", $12, $13, $14, $15)}' | sort | uniq -c | sort -

Ainda estou para encontrar uma resposta melhor; Eu gostaria de ter uma abordagem mais sutil e ser capaz de permitir seletivamente SSLv3 para determinados MTAs, dependendo se as tentativas de conexão falharem com certos erros em maillog . Todos os comentários / sugestões são bem-vindos.