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) garante 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?

O TLS-RPT (Transport Layer Security Reporting) é uma norma para comunicar problemas de entrega de correio eletrónico quando um correio eletrónico não está encriptado com TLS. A sua importância na autenticação de mensagens de correio eletrónico anda de mãos dadas 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 nas 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:[email protected];

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:[email protected]: 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:[email protected],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": "[email protected]",

"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!

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

Sobre
Últimos Posts

Yunes Tarada

Especialista em segurança de domínios e e-mails da PowerDMARC

Yunes é um Operations Team Lead na PowerDMARC com conhecimentos especializados em autenticação e segurança de correio eletrónico. Yunes é um Microsoft-certified Azure Administrator Associate com certificações em CompTIA A+ e muito mais.

Últimas mensagens de Yunes Tarada (ver todas)

PowerDMARC integra-se com o ConnectWise - 31 de outubro de 2024
O que é o Datagram Transport Layer Security (DTLS): Benefícios e desafios - 29 de outubro de 2024
DMARC e FedRAMP: Melhorar a segurança do correio eletrónico - 28 de outubro de 2024

O que é SMTP TLS Reporting?

Tabela de Conteúdos