Saltar para o conteúdo 
Vou mostrar-vos como Servidor de correio TLS no Postfix e selecionar conjuntos de cifras fortes para que as ligações SMTP sejam protegidas de forma consistente. Com base em parâmetros experimentados e testados para TLS 1.2/1.3, DANE, MTA-STS e pares de chaves modernos, guiá-lo-ei passo a passo através da configuração, teste e afinação para que o seu segurança do correio agarra de forma limpa.
Pontos centrais
- Postfix Configurar de forma segura: Ativar o TLS, restringir protocolos, definir o registo.
- Cifra dar prioridade: ECDHE + GCM/CHACHA20, aplicar o PFS, bloquear os dados antigos.
- Certificados manter limpo: RSA+ECDSA, cadeia completa, curvas fortes.
- DANE/MTA-STS utilizar: Orientações de ancoragem e redução dos riscos de desvalorização.
- Testes e monitorização: Verifique regularmente o OpenSSL, o scanner TLS e os registos MTA.
SMTP via TLS: o que é realmente seguro
Protejo o SMTP com STARTTLS, para que o transporte de correio eletrónico não seja feito em texto simples. TLS oportunista via smtpd_tls_security_level = may garante que as ligações de entrada utilizam a encriptação assim que a estação remota a oferece. Para as entregas de saída, utilizo smtp_tls_security_level = dane Verificações de políticas suportadas por DNSSEC para dificultar os ataques de downgrade. Sem o TLS, os emails podem ser lidos e manipulados em trânsito, o que é particularmente perigoso para formulários, encomendas ou dados de conta. Com o TLS ativo durante todo o processo, reduzo significativamente o risco de espionagem e de MITM, e obtenho melhores taxas de entrega porque os grandes fornecedores classificam favoravelmente as ligações seguras.
Chaves, certificados e protocolos no Postfix
Tenho dois certificados prontos: um RSA-e um certificado ECDSA para que os MTAs antigos e novos estejam ligados de forma óptima. Defino claramente os caminhos no Postfix, por exemplo smtpd_tls_cert_file para RSA e smtpd_tls_eccert_file para ECDSA, cada um com uma chave correspondente. Para uma autenticação limpa, presto atenção à cadeia completa, a um CN/SAN que corresponda exatamente ao anfitrião e a uma curva como secp384r1 para a chave ECDSA. Desactivo estritamente os protocolos mais antigos, ou seja, SSLv2 e SSLv3, para evitar descidas forçadas. Se estiver a ponderar o tipo de certificado, dê uma vista de olhos rápida a DV, OV ou EV, para escolher o nível de confiança correto.
Seleção de cifras: Prioridades para TLS 1.2/1.3
Dou prioridade aos conjuntos de cifras com PFS, ou seja, ECDHE antes de DHE, e usar GCM ou CHACHA20-POLY1305. No TLS 1.3, a pilha liberta-o de muitos problemas herdados, enquanto o TLS 1.2 continua a exigir uma lista clara. Suítes inseguras ou fracas, como RC4, Elimino o 3DES, o CAMELLIA, o aNULL e o eNULL. Para o Postfix, utilizo smtpd_tls_ciphers = high e uma diretiva restritiva tls_high_cipherlist, para que nenhum algoritmo desatualizado passe. Se formos mais fundo, o Guia de suítes de cifras uma categorização fácil de compreender e sem lastro.
| Versão TLS | Conjuntos de cifras favoritos | Estado | Nota |
|---|---|---|---|
| TLS 1.3 | TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256 | ativo | Seleção firmemente no protocolo, sem mais problemas de legado. |
| TLS 1.2 | ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-CHACHA20-POLY1305 | ativo | Dar prioridade à PFS, preferir GCM/CHACHA. |
| Obsoleto | RC4, 3DES, CAMELLIA, AES128-SHA, aNULL/eNULL | bloqueado | Desativar completamente por razões de segurança. |
Postfix: parâmetros concretos para main.cf
Defino uma configuração clara para que o MTA fale de forma segura tanto à entrada como à saída. Para a ECDH efémera, utilizo smtpd_tls_eecdh_grade e desactivei a compressão para evitar ataques do tipo CRIME. Um ficheiro DH forte com 4096 bits evita negociações DHE fracas. Coloco restrições rígidas nos protocolos e imponho uma qualidade de cifra elevada, favorecendo o TLS 1.3. No início, um nível de registo moderado ajuda-me a verificar os handshakes sem inundar o diário.
# Ativação e política
smtpd_tls_security_level = may
smtp_tls_security_level = dane
Certificados # (caminhos de exemplo)
smtpd_tls_cert_file = /etc/ssl/certs/mail.example.de.cer
smtpd_tls_key_file = /etc/ssl/private/mail.example.de.key
smtpd_tls_eccert_file = /etc/ssl/certs/mail.example.de_ecc.cer
smtpd_tls_eckey_file = /etc/ssl/private/mail.example.de_ecc.key
Protocolos e cifras #
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_ciphers = high
tls_high_cipherlist = !aNULL:!eNULL:!RC4:!3DES:!CAMELLIA:HIGH:@STRENGTH
tls_ssl_options = NO_COMPRESSION
smtpd_tls_eecdh_grade = ultra
Parâmetros # DH
smtpd_tls_dh1024_param_file = /etc/postfix/dh_4096.pem
# DNSSEC/DANE (se disponível)
smtp_dns_support_level = dnssec
# Registo de dados
smtpd_tls_loglevel = 1
Mantenho a cadeia de certificados completa, presto atenção aos direitos corretos para privado ficheiros de chaves e verificar os registos após o recarregamento. Se o TLS 1.2 for necessário para parceiros antigos, mantenho-me estritamente no GCM/CHACHA e bloqueio tudo o resto. Para o TLS 1.3, confio nos padrões da pilha e evito caminhos especiais que dificultam a manutenção. O agrafamento OCSP só desempenha um papel no SMTP se um proxy a montante o fornecer, pelo que só o verifico nas configurações correspondentes. Após cada mudança, eu valido com o OpenSSL para reconhecer efeitos colaterais logo no início e para garantir que o encriptação de correio eletrónico de forma coerente.
Autenticidade de transporte com DANE, MTA-STS, SPF, DKIM e DMARC
Combino TLS com DANE, publicando registos TLSA assinados ao abrigo do DNSSEC. Além disso, defino o MTA-STS para que os pares remotos saibam que o meu anfitrião requer TLS e a que MX devem aderir. Para a ligação de identidade, assino os emails de saída com DKIM e entrega segura de domínios através de regras SPF. Por último, o DMARC define a forma como os destinatários devem lidar com os desvios, o que torna a falsificação muito mais difícil. Estes componentes funcionam em conjunto: O TLS protege o transporte, enquanto a autenticação reforça o remetente e aumenta visivelmente a taxa de entrega.
Se o desempenho for um estrangulamento, optimizo o reinício da sessão, as funcionalidades de hardware e o próprio aperto de mão. Pode começar a utilizar truques práticos com Aperto de mão TLS mais rápido, para reduzir a latência ao estabelecer uma ligação. Importante: mantenho a seleção de cifras e a retoma em equilíbrio, porque os compromissos fracos não compensam em termos de segurança. A negociação rápida do TLS traz economias significativas, especialmente com grandes volumes de correio. Desta forma Rendimento e a segurança em equilíbrio.
Testes, controlo e auditorias
Verifico os apertos de mão localmente com openssl e verificar a versão do protocolo, a cifra e a cadeia de certificados. O comando openssl s_client -connect mail.example.de:25 -starttls smtp mostra-me ao vivo o que o servidor remoto está a negociar. Após as alterações de configuração, utilizo verificação postfix e analisar especificamente smtpd_tls_loglevel, para isolar padrões de erro. Os scanners externos de TLS ajudam a categorizar a visibilidade pública, especialmente após alterações de certificados. Um ciclo de auditoria regular protege contra a deterioração progressiva, por exemplo, se uma alteração da biblioteca afetar as prioridades de cifra.
Erros de configuração frequentes e correcções rápidas
Vejo frequentemente cifras desactualizadas como AES128-SHA, que ainda estão activos e impedem o PFS. Uma cadeia de cifras rigorosa e o bloqueio claro de LOW/MD5/RC4/3DES ajudam aqui. Segundo padrão: falta de certificados intermédios, o que impede as estações remotas de verificar a cadeia; adiciono o ficheiro do pacote e testo novamente. Em aparelhos como um Synology, defino o perfil TLS como moderno e removo as opções herdadas para que o servidor SMTP fale moderno. Com o Microsoft Exchange, verifico especificamente as políticas TLS 1.2/1.3, a atribuição de certificados por conetor e quaisquer substituições de cifra na configuração do anfitrião para que o Aperto de mão-A seleção é correta.
Pré-visualização: TLS 1.3, 0-RTT e Post-Quantum
Prefiro o TLS 1.3 porque o aperto de mão é mais curto e as opções antigas são omitidas, o que reduz as superfícies de ataque. A seleção da opção cifra Não utilizo o 0-RTT no contexto do SMTP, uma vez que os ataques de repetição trazem riscos desnecessários. Para o futuro, estou atento aos procedimentos híbridos pós-quânticos, que poderão entrar no ambiente de correio assim que a normalização e o suporte amadurecerem. Continua a ser importante definir as políticas e o controlo de forma a que os novos procedimentos possam ser integrados mais tarde sem perturbações.
Desempenho e taxa de entrega num relance
Eu meço o Latência do aperto de mão TLS e otimizar as caches para permitir a reutilização. A retoma da sessão (bilhetes/IDs) reduz a carga informática e acelera as ligações recorrentes entre MTAs. Para a revogação de certificados, baseio-me em informações empilháveis no proxy a montante, se disponíveis, para poupar acessos adicionais. Os grandes destinatários avaliam favoravelmente os transportes seguros, o que aumenta a taxa de entrega, enquanto os caminhos inseguros aumentam o risco de spam e rejeição. Com uma política TLS clara, entradas DNS sólidas e uma cadeia de assinaturas limpa, crio uma base fiável para Capacidade de entrega.
O meu calendário de instalação
Começo por obter o certificado de uma CA fiável, gero ECDSA e RSA e armazeno ambos de forma limpa no anfitrião. De seguida, personalizo o ficheiro main.cf com os parâmetros TLS, definir cifras fortes e desativar protocolos antigos. É adicionado um novo ficheiro DH com 4096 bits, seguido de um recarregamento e das primeiras verificações OpenSSL. Em seguida, configuro o DANE, adiciono o MTA-STS e verifico a validade do SPF/DKIM/DMARC. Por fim, executo testes contra alvos externos, verifico os registos durante o funcionamento e programo auditorias regulares para que o Configuração permanece seguro a longo prazo.
Módulos em falta: Submissão, SMTPS e SNI
Não só protejo a porta 25, como também o envio (587) e, opcionalmente, o SMTPS (465). Para o envio, imponho a encriptação e a autenticação para que as palavras-passe dos utilizadores nunca sejam enviadas em texto simples. Em master.cf Ativo os serviços e defino substituições específicas:
Envio # (porta 587) com STARTTLS e obrigação de autenticação
submission inet n - y - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_tls_auth_only=yes
-o smtpd_sasl_auth_enable=yes
-o milter_macro_daemon_name=ORIGINANDO
# SMTPS (porta 465) como modo wrapper, se necessário
smtps inet n - y - - smtpd
-o syslog_name=postfix/smtps
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o milter_macro_daemon_name=ORIGINANDO
Se servir vários domínios de correio eletrónico num único anfitrião com os meus próprios certificados, utilizo SNI. Utilizo um mapa SNI para atribuir o caminho de certificado adequado a cada anfitrião de destino e garantir que os clientes MUA também vêem o certificado correto. É assim que asseguro a separação do cliente com uma identidade TLS consistente.
Políticas por domínio: controlo de precisão
Para além da política global, também faço a gestão de smtp_tls_policy_maps Excepções e restrições por domínio destinatário. Isto permite-me migrar gradualmente parceiros antigos ou impor requisitos particularmente rigorosos para alvos sensíveis.
# main.cf
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
# /etc/postfix/tls_policy (entradas de exemplo)
example.org só pode ser usado
legacy.example.net pode
secure.example.com secure
apenas dinamarquês aplica a proteção DANE sem dependência da AC, seguro requer uma cadeia CA válida e recusa a entrega de texto simples, pode continua a ser oportunista. Após as alterações, construo o mapa com mapa postal e recarregar o Postfix.
DANE e MTA-STS: aplicação concreta
Para DANE Publico registos TLSA ao abrigo do DNSSEC. Prefiro utilizar o DANE-EE (311) porque permite a fixação da chave pública e facilita a alteração de certificados com a mesma chave. Um registo TLSA exemplar em _25._tcp.mail.example.de tem este aspeto:
_25._tcp.mail.example.de. IN TLSA 3 1 1
Eu gero o hash a partir do certificado ECDSA ou RSA e certifico-me de o rodar antes de expirar. É importante que a zona DNS seja assinada e que a cadeia de delegações seja validada sem lacunas.
Para MTA-STS Alojo o ficheiro de política através de HTTPS e adiciono a entrada DNS TXT. Desta forma, especifico que os pares remotos falam TLS e só são aceites com um MX definido. Um ficheiro de política minimalista:
versão: STSv1
modo: impor
mx: mail.example.de
max_age: 604800
É adicionada uma entrada TXT no DNS em _mta-sts.example.de com a versão atual. Opcionalmente, configuro TLS-RPT via TXT em _smtp._tls.example.de para receber relatórios sobre violações de políticas. Esta telemetria ajuda-me a reconhecer falhas, desclassificações e certificados defeituosos numa fase inicial.
Reforçar os protocolos, especificar a cifra
Reforço os limites do protocolo e imponho a preferência do servidor. O TLS 1.0/1.1 é dispensável atualmente; apenas permito o TLS 1.2 e 1.3 em profundidade e numa base de saída. Para o TLS 1.2, defino uma lista positiva explícita para excluir stocks mistos de cifras antigas:
# Reforço adicional (main.cf)
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
# Lista de cifras explícita do TLS 1.2 (apenas PFS + AEAD)
tls_high_cipherlist = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:!aNULL:!eNULL:!MD5:!RC4:!3DES:!CAMELLIA
# Utilizar a preferência do servidor
tls_preempt_cipherlist = sim
Certifico-me de que o ECDHE é privilegiado e que o DHE é apenas um recurso. Mantenho o meu ficheiro DH atualizado; no TLS 1.3 não desempenha qualquer papel, mas continua a ser útil para acções raras de DHE.
Retomada de sessão e caches
Para acelerar as coisas, ativo as caches de sessão para o cliente e o servidor para tornar as reconexões mais favoráveis. A carga da CPU e a latência são visivelmente reduzidas, especialmente com alta taxa de transferência de correio:
# Cache de sessão (main.cf)
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtp_tls_connection_reuse = yes
Controlo a taxa de acertos nos registos e certifico-me de que nenhum é demasiado curto. duração dos bilhetes na biblioteca TLS para abrandar a retoma. Importante: A retoma não deve enfraquecer a política; mantenho os mesmos requisitos de cifra.
Empresa certificada: Rotação e manutenção da corrente
Automatizo a renovação e o recarregamento do MTA para que nenhum certificado expirado fique em funcionamento. Após cada renovação, verifico se os certificados folha e intermédios estão completamente no pacote. Para a operação dupla ECDSA/RSA, certifico-me de que ambos os pares rodam antes de uma alteração em massa causar problemas aos clientes. Testo o caminho e a submissão do SNI separadamente porque os MUAs podem apresentar padrões de erro diferentes dos MTAs.
Aprofundar o registo e o diagnóstico
Aumento temporariamente a profundidade do registo quando ocorre um problema e utilizo ferramentas de bordo para verificações cruzadas:
Registo direcionado para o # (main.cf)
smtp_tls_loglevel = 1
smtp_tls_note_starttls_offer = yes
Com posttls-finger target.example.com Verifico que política um MTA remoto espera e que cifras/protocolos são negociados. Utilizo postconf -n | grep tls, para ver apenas os parâmetros TLS definidos explicitamente; posso encontrar desvios dos padrões mais rapidamente dessa forma. Nos registos, procuro por termos como sem cifra partilhada, falha na verificação do certificado ou versão do protocolo, que indicam diretamente incompatibilidade de cifras, problemas de cadeia ou limites de protocolo demasiado rígidos/ demasiado frouxos.
Gerir a compatibilidade sem sacrificar a segurança
Planeio as transições de forma consciente: mantenho-me a par de pode, para evitar a perda de correio eletrónico de servidores antigos, mas registo as entregas em texto simples. Na saída, mantenho-me rigoroso (DANE/MTA-STS/secure) e utilizo smtp_tls_policy_maps para casos individuais. Se os parceiros individuais só conseguirem gerir o TLS 1.2 com AES-GCM, isso é aceitável; eu faço a gestão de tudo o que está abaixo disso através de excepções acordadas com um tempo de execução limitado, documento-as e incluo-as no planeamento da migração. Isto mantém o nível geral elevado sem bloquear as operações comerciais.
Visão geral das predefinições TLS do sistema
Tenha em atenção que o Postfix utiliza a biblioteca TLS do sistema. As actualizações do OpenSSL/LibreSSL podem alterar as prioridades de cifra e o comportamento do TLS 1.3. Após as actualizações do sistema, eu verifico aleatoriamente os handshakes e comparo a saída de postconf -n com os meus valores-alvo. Um conjunto nível_de_compatibilidade no Postfix ajuda a manter padrões estáveis, mas eu não confio cegamente nele e documento desvios explícitos no main.cf/master.cf.
Resumo rápido para administradores
Gostaria de sublinhar que cifras fortes com PFS, certificados limpos e políticas claras são essenciais para SMTP crucial. O TLS 1.3 liberta-o dos problemas herdados, enquanto o TLS 1.2 exige uma lista de cifras disciplinada. DANE e MTA-STS reforçam o caminho de transporte, SPF/DKIM/DMARC protegem a identidade e a comunicação. Testes regulares e análises de registos mostram desde logo se uma alteração tem efeitos secundários indesejáveis. Com este guia, pode configurar o seu servidor de correio eletrónico para ser seguro, ter um bom desempenho e estar preparado para o futuro - sem necessidade de Riscos.
