TLS-RPT Generator

Como usar este gerador TLS-RPT

Passo 1: Adicionar destinos de relatório

Indique onde pretende receber os relatórios de falhas de TLS:

Email (recomendado para começar)

mailto:tlsrpt@captaindns.com

Webhook HTTPS (para automação)

https://tlsrpt.captaindns.com/v1/report

Pode adicionar vários destinos: os relatórios são enviados para todos.

Passo 2: Copiar o registo gerado

O gerador cria um registo RFC 8460 válido:

v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com

Passo 3: Publicar no DNS

Crie um registo TXT em _smtp._tls.captaindns.com com o valor gerado.

Exemplo para captaindns.com:

• Tipo: TXT
• Host: _smtp._tls
• Valor: v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com

Passo 4: Verificar a publicação

Use o nosso TLS-RPT Checker para confirmar que a configuração está correta.

O que o TLS-RPT realmente relata

O TLS-RPT é uma ferramenta de observabilidade pura: nunca altera o comportamento de um servidor; revela o que realmente aconteceu durante as ligações TLS de entrada para os seus MX.

Os operadores emissores assinalam-lhe nomeadamente:

• um downgrade ou stripping de STARTTLS, em que a sessão volta a texto claro
• um certificado expirado, não fiável ou autoassinado
• um certificado cujo hostname não corresponde ao MX esperado
• a falha na obtenção ou validação de uma política MTA-STS
• uma falha DANE: registo TLSA inválido ou cadeia DNSSEC quebrada

O TLS-RPT não aplica nenhuma regra. A recusa em entregar uma mensagem em texto claro vem do MTA-STS ou do DANE; o TLS-RPT limita-se a dizer-lhe quando e porque a encriptação falhou, para que possa corrigir antes de passar a enforce.

Formato do registo TLS-RPT

Componentes obrigatórios

Esquemas de URI suportados

mailto: - Entrega por email

rua=mailto:equipa-seguranca@captaindns.com

Os relatórios chegam como anexos JSON comprimidos.

https: - Entrega por webhook

rua=https://api.captaindns.com/tlsrpt/ingest

Os relatórios são enviados via POST, em formato JSON, com o cabeçalho Content-Type: application/tlsrpt+gzip

Múltiplos destinos

Separe-os por vírgulas:

v=TLSRPTv1; rua=mailto:reports@captaindns.com,https://tlsrpt.captaindns.com/report

Enviar os relatórios para um domínio terceiro

Uma rua que aponta para um domínio diferente do seu funciona tal como está, sem qualquer registo de autorização do lado do destinatário.

Esta é uma diferença importante em relação ao DMARC. O DMARC exige um registo _report._dmarc no domínio terceiro antes de aceitar relatórios cross-domain. A RFC 8460 afastou deliberadamente esse mecanismo (secção 7): o risco de amplificação com o TLS-RPT é menor do que com o DMARC e a confiança é assegurada de outra forma. Os relatórios mailto: são assinados com DKIM pelo operador emissor, e os relatórios https: assentam na posse do DNS e do certificado do endpoint.

v=TLSRPTv1; rua=mailto:reports@tlsrpt-service.com

Não é necessária qualquer ação em tlsrpt-service.com para que esta rua seja válida.

Para manter a simplicidade, um endereço no seu próprio domínio é suficiente na maioria dos casos:

v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com

Exemplos por fornecedor de DNS

Cloudflare

1. Aceda às definições de DNS do seu domínio
2. Adicione um registo:
   • Tipo: TXT
   • Nome: _smtp._tls
   • Conteúdo: o valor do registo gerado
   • TTL: Auto

AWS Route 53

1. Abra a zona alojada do seu domínio
2. Crie um registo:
   • Nome do registo: _smtp._tls
   • Tipo de registo: TXT
   • Valor: "v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com"
   • TTL: 3600

OVH / Google Domains

1. Aceda à zona DNS
2. Adicione uma entrada:
   • Subdomínio: _smtp._tls
   • Tipo: TXT
   • Destino: o valor do registo gerado
   • TTL: 3600

Compreender os relatórios TLS-RPT

Um relatório TLS-RPT é um documento JSON agregado, comprimido com gzip, que resume as sessões TLS de um operador para o seu domínio ao longo de um dia.

Anatomia de um relatório

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2024-01-15T00:00:00Z",
    "end-datetime": "2024-01-16T00:00:00Z"
  },
  "contact-info": "postmaster@google.com",
  "report-id": "2024011512345",
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-string": ["version: STSv1", "mode: enforce", "mx: mail.captaindns.com", "max_age: 604800"],
      "policy-domain": "captaindns.com"
    },
    "summary": {
      "total-successful-session-count": 8432,
      "total-failure-session-count": 3
    },
    "failure-details": [{
      "result-type": "certificate-expired",
      "sending-mta-ip": "198.51.100.1",
      "receiving-mx-hostname": "mail.captaindns.com",
      "failed-session-count": 3
    }]
  }]
}

Os tipos de falha (result-type)

O registo IANA define 11 valores possíveis para result-type:

Os tipos de política (policy-type)

Cada sessão está associada a um dos 3 policy-type:

Transporte e cadência

Todos os relatórios são comprimidos com gzip. Existem dois canais de entrega, conforme o esquema da sua rua:

• HTTPS: o relatório é enviado via POST com o cabeçalho Content-Type: application/tlsrpt+gzip (ou application/tlsrpt+json). O endpoint confirma a receção com um estado 2xx.
• Email: a mensagem é um multipart/report; report-type="tlsrpt" com um anexo application/tlsrpt+gzip. Inclui os cabeçalhos TLS-Report-Domain e TLS-Report-Submitter, um assunto da forma Report Domain: captaindns.com Submitter: google.com Report-ID: 2024011512345, e é assinada com DKIM com o seletor s=tlsrpt.

Cadência: cada operador emissor envia um relatório agregado por dia, cobrindo a janela das 00:00 às 24:00 UTC. Em caso de falha de entrega, tenta de novo até 24 horas.

Quem envia os relatórios

Os grandes operadores emitem relatórios TLS-RPT: a Google, a Microsoft e o Yahoo fazem-no sistematicamente; a Apple e a Comcast também já foram assinaladas. Cada operador produz o seu próprio relatório independente, pelo que pode receber vários por dia, um por emissor.

TLS-RPT com MTA-STS e DANE

O TLS-RPT é o ciclo de observabilidade do MTA-STS e do DANE. Estes protocolos impõem a encriptação; o TLS-RPT mostra-lhe o efeito dessa imposição, antes e depois da entrada em produção.

Ordem de implementação recomendada

1. Publicar o TLS-RPT, e o MTA-STS em mode: testing
2. Analisar os relatórios durante 2 a 4 semanas
3. Passar o MTA-STS para mode: enforce
4. Continuar a monitorização via TLS-RPT

Passar a enforce sem TLS-RPT é avançar às cegas: se uma política quebrar a entregabilidade, só o saberá pelas queixas dos utilizadores.

Ferramentas relacionadas

• Gerar uma política MTA-STS
• Verificar o estado MTA-STS
• Verificar o estado TLS-RPT
• Verificar os registos DANE TLSA

Boas práticas e armadilhas comuns

Boas práticas

• Aponte a rua para uma caixa ou endpoint dedicado, capaz de absorver o volume e de analisar o JSON. Nunca uma caixa humana: os relatórios chegam todos os dias, em JSON comprimido com gzip, de cada operador.
• Use uma ferramenta de agregação para transformar estes relatórios em tendências acionáveis, em vez de os abrir um a um.

Armadilhas a evitar

• Dois registos TXT em _smtp._tls tornam a configuração inválida. Mantenha um único registo com um único valor.
• Aplique percent-encoding aos caracteres ,, ! e ; quando aparecem numa URI (por exemplo num mailto: com parâmetros), caso contrário o parsing do registo quebra.

Casos de uso concretos

Cada cenário abaixo traduz-se num result-type preciso nos seus relatórios:

• Um MX de backup nunca configurado para TLS: starttls-not-supported. Deteta-o antes que um atacante tire partido disso.
• O certificado de um parceiro expirou: certificate-expired nas sessões em causa.
• Um MX apresenta um certificado emitido para o hostname errado: certificate-host-mismatch.
• Um downgrade ativo de STARTTLS (ataque na rede) faz cair as sessões encriptadas: pico de starttls-not-supported.
• A sua própria política MTA-STS está quebrada ou inacessível: sts-policy-fetch-error ou sts-policy-invalid, antes que bloqueie correio legítimo.
• Um DANE mal configurado: tlsa-invalid (TLSA que deixou de corresponder após uma rotação de certificado) ou dnssec-invalid (cadeia DNSSEC quebrada).

Ferramentas complementares

Recursos úteis

• RFC 8460 - SMTP TLS Reporting (especificação oficial)
• RFC 8461 - MTA-STS (protocolo complementar)
• Google - Configurar TLS reporting
• Postfix - Documentação TLS