Como as organizações dependem cada vez mais do correio eletrónico como principal meio de comunicação, a importância de fortificar estes canais contra potenciais ameaças não pode ser exagerada. A segurança da camada de transporte (TLS) é a pedra angular para garantir a confidencialidade e a integridade dos dados transmitidos através das redes.
Vários protocolos ajudam a encriptar os canais de mensagens SMTP para evitar que os ciberataques interceptem as comunicações por correio eletrónico. Isto inclui STARTTLS, DANE e MTA-STS. No entanto, quando as tentativas de encriptação falham ao utilizar estes protocolos, o seu correio eletrónico pode não ser entregue. TLS-RPT (conforme descrito em RFC 8460) fornece um mecanismo de feedback para comunicar estas falhas de entrega.
Recomendamos vivamente a utilização do TLS-RPT em conjunto com o MTA-STS protocolo. Vamos perceber como estes protocolos funcionam em conjunto para reforçar a segurança do correio eletrónico.
O que é o TLS-RPT?
TLS-RPT significa Transport Layer Security Reporting (Relatório de segurança da camada de transporte). É uma norma para comunicar problemas de entrega de correio eletrónico que ocorrem quando um correio eletrónico não está encriptado com TLS. A sua importância na autenticação de mensagens de correio eletrónico vai de par com a razão para ativar a encriptação TLS para mensagens de correio eletrónico.
A encriptação TLS garante que todas as mensagens de correio eletrónico que lhe são enviadas são entregues em segurança. Se a ligação não for segura, muitas vezes as mensagens de correio eletrónico podem não ser entregues. O TLS-RPT permite aos proprietários de domínios monitorizar a entrega de correio eletrónico e as falhas de ligação. Os relatórios podem conter informações sobre:
- Problemas de tratamento da política do MTA-STS
- Motivo e tipo da falha de entrega
- Endereço IP dos agentes de transferência de correio eletrónico de envio e receção
- Contagem total de sessões de ligação TLS bem sucedidas e não bem sucedidas
Isto proporciona visibilidade dos seus canais de correio eletrónico e a capacidade de combater mais rapidamente os desafios de capacidade de entrega.
Como funciona o relatório TLS?
Na comunicação por correio eletrónico SMTP, a encriptação TLS é "oportunista". Isto significa que, se não for possível negociar um canal encriptado, o correio eletrónico continua a ser enviado num formato não encriptado (texto simples). De facto, há quase quatro décadas, os protocolos de correio eletrónico SMTP não suportavam a encriptação TLS. Teve de ser adaptada mais tarde sob a forma do comando STARTTLS.
O comando STARTTLS só é emitido em comunicações SMTP, se ambas as partes suportarem a encriptação TLS. Caso contrário, a mensagem de correio eletrónico continuará a ser enviada em texto simples.
Para eliminar a encriptação oportunista no SMTP, foi introduzido o MTA-STS (RFC 8461). O protocolo MTA-STS garante que as mensagens de correio eletrónico são encriptadas antes de serem entregues. O servidor de correio eletrónico ou o agente de transferência de correio (MTA) negoceia com o servidor recetor para ver se este suporta o comando STARTTLS. Se for compatível, a mensagem de correio eletrónico é encriptada com TLS e é entregue. Caso contrário, a entrega falha.
Pode haver várias razões para as falhas de encriptação TLS. Para além da falta de suporte para encriptação em ambos os lados, razões mais sinistras, como um ataque de downgrade SMTP, podem levar à falha da ligação TLS. Com o MTA-STS ativado, os atacantes não conseguem entregar mensagens em texto simples quando uma ligação falha.
Mas os proprietários de domínios gostariam de saber que a entrega falhou. O relatório TLS (TLS-RPT) é um protocolo que o notificará. Em caso de falhas de entrega, receberá o seu relatório TLS num formato de ficheiro JSON para o endereço de correio eletrónico definido no seu registo TLS-RPT.
Porque precisa de relatórios SMTP TLS?
Os proprietários de domínios precisam de se manter informados sobre o correio eletrónico d
problemas de entrega devido a falhas na encriptação TLS para mensagens de correio eletrónico enviadas a partir de um domínio com MTA-STS ativado. A comunicação TLS torna-o possível ao fornecer esta informação. TLS-RPT
- Para receber relatórios de feedback que destacam o seu tipo de apólice e
- Para identificar o motivo das falhas de encriptação TLS
- Para ganhar visibilidade nos canais de correio eletrónico
- Para resolver problemas de entrega
Passos para configurar o TLS-RPT
Pode ativar o relatório TLS para o seu domínio criando um registo TXT para TLS-RPT e publicando-o no seu DNS. Este registo tem de ser publicado no subdomínio smtp.tls.yourdomain.com
Passo 1: Selecionar uma ferramenta de geração de registos TLS-RPT
Pode inscrever-se no PowerDMARC gratuitamente e utilizar o nosso gerador de registos TLS-RPT para criar o seu registo.
Passo 2: Introduza o seu endereço de correio eletrónico de comunicação
Introduza um endereço de correio eletrónico no qual pretende receber os seus relatórios SMTP TLS.
Passo 3: Publique o registo TLS no seu DNS
Pode contactar o seu fornecedor de serviços de registo de domínios para criar um novo registo TXT para TLS-RPT. Se gerir o seu próprio DNS, edite as suas definições de DNS para incluir o registo.
Exemplo de registo TLS-RPT
Sintaxe: v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com;
Vamos analisar os 2 componentes do registo de comunicação TLS fornecido:
- v=TLSRPTv1: Esta etiqueta especifica a versão do protocolo TLS-RPT que está a ser utilizada. Neste caso, "TLSRPTv1" indica a primeira versão do protocolo.
- rua=mailto:tlsrpt@yourdomain.com: rua significa "Reporting URI(s) for Aggregate Data". Esta etiqueta especifica para onde o servidor de correio do destinatário deve enviar os relatórios TLS agregados.
Pode configurar mais do que um destino para receber os seus relatórios. Para vários destinos, separe cada entrada com uma vírgula (,). Pode utilizar "maito:" para especificar um endereço de correio eletrónico para este passo ou dar instruções ao MTA para enviar relatórios através de POST para URLs de ponto final, utilizando "https:" no campo rua=. Se estiver a utilizar "https:" certifique-se de que o campo define o URL para um servidor Web ativado por HTTPS com um certificado válido. Tanto "mailto:" como "https:" também podem ser utilizados num único registo, separados por uma vírgula.
Exemplo: v=TLSRPTv1; rua=mailto:tlsrpt@example.com,https://tlsreport.example.com;
Nota: Na prática, substitui-se "seudomínio.com" pelo nome de domínio real onde pretende receber estes relatórios.
Formato do relatório TLS
Os relatórios TLS são enviados no formato JSON. Abaixo está um exemplo de como pode ser um relatório JSON TLS:
{
"organization-name": "Organização Inc.",
“date-range”: {
"start-datetime": “2020-10-22T00:00:00Z”,
"end-datetime": “2020-10-22T23:59:59Z”
},
"contacto-info": "smtp-tls-reporting@organization.com",
"report-id": “2020-10-22T00:00:00Z_domain.com”,
"políticas": [
{
“policy”: {
"tipo de política": "sts",
"policy-string": [
"versão: STSv1",
"mode: testing",
"mx: mx.domain.com",
"mx: mx2.domain.com",
"mx: mx3.domain.com",
"max_age: 604800"
],
"domínio da política": "domínio.com"
},
“summary”: {
"total-successful-session-count": 15,
"total-failure-session-count": 0
}
Eis a repartição dos principais campos deste relatório JSON TLS:
| Campos | Descrição |
| organização | A organização do domínio que possui o registo TLS-RPT. |
| correio eletrónico | O endereço de correio eletrónico para onde são enviados os relatórios agregados. |
| data_inicial | A data de início do período de referência. |
| data_final | A data final do período de referência. |
| políticas | Um conjunto de objectos de política que descrevem as políticas aplicadas durante o período de referência. |
| política | Contém informações sobre a política aplicada. |
| tipo de política | Especifica o tipo de política |
| cadeia_de_políticas | Especifica a cadeia de políticas associada à política |
| modo | Especifica o modo de política MTA-STS (Aplicar/Testar) |
| resumo | Contém informações resumidas sobre as sessões que foram tentadas. |
| total_successful_session_count | O número total de sessões TLS estabelecidas com êxito. |
| total_failure_session_count | A contagem total de falhas de sessão TLS. |
| detalhes_da_falta | Um conjunto de objectos que fornecem detalhes sobre falhas específicas. |
| razão | Uma cadeia de caracteres que indica o motivo da falha (por exemplo, "certificate_expired"). |
| contagem | A contagem de sessões que falharam por um motivo específico. |
Razões e tipos de falhas de encriptação TLS
Questões de certificados
| Tipos de falhas | Razões | Possíveis sugestões de resolução de problemas |
| certificado_expirado | O certificado apresentado pelo servidor remoto ultrapassou a data de expiração. Isto torna-o não fiável para a encriptação. | Renovar o seu certificado. |
| certificate_not_valid_yet | O certificado apresentado pelo servidor remoto ainda não é válido. Isto pode dever-se a uma hora incorrecta do servidor ou à utilização prematura do certificado. | Contacte o seu fornecedor de certificados. |
| certificado_revogado | O certificado apresentado pelo servidor remoto foi revogado pela autoridade de certificação devido a questões de segurança. | Contacte o seu fornecedor de certificados. |
| assinatura_não_válida | A cadeia de certificados apresentada pelo servidor remoto não é de confiança para o servidor ou cliente de correio eletrónico do remetente, indicando um potencial risco de segurança. | Contacte o seu fornecedor de certificados. |
| certificado não suportado | O certificado apresentado pelo servidor remoto utiliza algoritmos de encriptação ou comprimentos de chave que não são suportados pelo servidor de correio do remetente, impedindo uma ligação segura. | Contacte o seu fornecedor de certificados. |
Incompatibilidade de nome de anfitrião e identidade
| Tipo de falha | Motivo | Possíveis sugestões de resolução de problemas |
| incompatibilidade de nome de anfitrião | O nome de anfitrião especificado no certificado do servidor não corresponde ao nome de anfitrião do servidor ao qual o servidor de correio do remetente está a tentar ligar. Isto indica um possível ataque man-in-the-middle ou um problema de configuração. | Verifique os registos MX no seu ficheiro de política MTA-STS para se certificar de que correspondem ao registo MX do domínio. |
Questões de handshake e protocolo
| Tipos de falhas | Razões | Possíveis sugestões de resolução de problemas |
| handshake_failure | Ocorreu um problema durante o processo inicial de handshake TLS entre o servidor de correio do remetente e o servidor de correio do destinatário, impedindo o estabelecimento do canal seguro. | Verifique novamente se a ligação SMTP STARTTLS foi estabelecida. Podem existir várias razões que contribuem para as falhas de encriptação, como a falta de suporte para STARTTLS ou um ataque de downgrade de TLS. |
Questões políticas do MTA-STS
| Tipos de falhas | Razões | Possíveis sugestões de resolução de problemas |
| mta_sts_policy_not_found | Esta falha ocorre quando o servidor de correio do remetente não consegue encontrar uma política MTA-STS para o domínio do destinatário. | Reveja o ficheiro de política do MTA-STS.
Verifique o seu registo MTA-STS para se certificar de que foi publicado corretamente. |
| mta_sts_policy_invalid | Esta falha ocorre quando a política MTA-STS encontrada no DNS para o domínio do destinatário é inválida, contém erros ou não cumpre a especificação MTA-STS. | Reveja o ficheiro de política do MTA-STS.
Especifique um modo de política MTA-STS adequado. Pode ser Nenhum, Aplicar ou Teste. Isto dá instruções aos servidores de envio sobre como tratar os e-mails que sofrem falhas de validação da política MTA-STS. Saiba mais sobre os modos de política aqui. |
| mta_sts_policy_fetch_error | Esta falha ocorre quando o servidor de correio do remetente encontra um erro ao tentar recuperar a política MTA-STS dos registos DNS do domínio do destinatário. | Valide os registos MTA-STS no seu DNS para se certificar de que a sintaxe do registo está correcta. |
| mta_sts_connection_failure | Esta falha ocorre quando o servidor de correio do remetente tenta estabelecer uma ligação segura utilizando o MTA-STS, mas falha devido a razões como certificados não fidedignos, conjuntos de cifras não suportados ou outros problemas de TLS. | Verifique a validade do seu certificado, certifique-se de que o certificado está atualizado com a norma TLS mais recente. |
| mta_sts_invalid_hostname | Esta falha ocorre quando o nome do anfitrião do servidor de correio do destinatário, conforme especificado na política MTA-STS, não corresponde ao nome real do anfitrião do servidor. | Verifique os registos MX no seu ficheiro de política MTA-STS para se certificar de que correspondem ao registo MX do domínio. |
Relatórios SMTP TLS simplificados com o PowerDMARC
A experiência de relatório SMTP TLS do PowerDMARC visa melhorar sua segurança e facilitar sua vida com um serviço hospedado.
Relatórios traduzidos de TLS
Os seus complexos relatórios TLS-RPT JSON são convertidos em informações simplificadas que pode consultar em segundos ou ler em pormenor.
Questões de auto-detecção
A plataforma PowerDMARC identifica e destaca o problema que está a enfrentar para que possa resolvê-lo sem perder tempo.
Não há uma única coisa de que eu goste na plataforma PowerDMARC, eles têm um layout fácil de usar e entender com o que eu chamaria de recursos completos que permitem o controle DMARC hospedado, achatamento SPF, sendo capaz de expandir facilmente o SPF inclui para inspecionar as especificidades do registro e até mesmo suporte completo para MTA-STS e TLS-RPT!
Dylan B (Proprietário da empresa)
Perguntas frequentes sobre a segurança da camada de transporte
1. O que significa TLS?
TLS significa Transport Layer Security (Segurança da Camada de Transporte).
2. Quem emite os certificados TLS?
As Autoridades de Certificação (CAs) podem emitir certificados TLS. O processo de emissão do certificado inclui a verificação da identidade do titular do certificado. Se a identificação for bem sucedida, o certificado é emitido.
3. Porque é que preciso de um certificado TLS?
Os certificados TLS desempenham um papel fundamental na proteção das comunicações através da Internet. Ajudam a encriptar informações sensíveis trocadas entre servidores Web em comunicação. Algumas das suas utilizações mais comuns incluem a segurança das comunicações por correio eletrónico e HTTPS.
4. Qual é a norma TLS atual?
O TLS 1.3 é a versão mais recente do Transport Layer Security. O TLS-RPT pode ser implementado utilizando qualquer versão do TLS. Isto pode incluir versões mais antigas do protocolo ou versões futuras. A versão é normalmente determinada por critérios como as capacidades dos servidores em comunicação.
Recursos adicionais
- SPF Softfail Vs Hardfail: Qual é a diferença? - 26 de abril de 2024
- A FTC informa que o correio eletrónico é um meio popular para as burlas de falsificação de identidade - 16 de abril de 2024
- SubdoMailing e a ascensão do phishing de subdomínio - 18 de março de 2024