Entrega encriptada: TLS, MTA-STS e DANE

Módulo 5: Reputação e os grandes destinatários · Tempo de leitura: 10 minutos

Objetivo de aprendizagem: Após esta lição, saberá explicar como os servidores de correio encriptam entre si, porque isso não é obrigatório por omissão e o que o MTA-STS, o TLS-RPT e o DANE alteram nisso. Será capaz de consultar e interpretar os registos correspondentes.

Conceitos-chave: STARTTLS entre servidores, encriptação oportunista, ataque de downgrade, MTA-STS (RFC 8461), registo _mta-sts, ficheiro de política, modo testing/enforce/none, TLS-RPT (RFC 8460), registo _smtp._tls, DANE para SMTP (RFC 7672), registo TLSA, DNSSEC

Dois tipos de ligações

Na lição 1.4 falou-se da ligação entre o seu programa de correio eletrónico e o servidor de correio do seu fornecedor: porta 587 com STARTTLS, ou 465 com TLS direto, com início de sessão. Aí, é você quem controla a situação. O seu programa sabe que servidor espera, verifica o certificado e recusa estabelecer ligação se algo não estiver correto.

Esta lição trata do passo seguinte: a ligação entre o servidor de envio e o servidor de receção, na porta 25. Essa funciona de forma diferente.

Oportunista: encriptar quando possível

Quando um servidor entrega correio, estabelece ligação com o MX do destinatário. Depois do EHLO, verifica se o servidor recetor oferece STARTTLS. Se sim, muda para uma ligação encriptada. Se não, entrega o correio sem encriptação.

A isto chama-se encriptação oportunista: encriptar quando possível, senão não. E, na maioria dos casos, o servidor de envio não verifica rigorosamente o certificado. Um certificado expirado ou autoassinado não é então motivo para interromper o processo.

Porquê assim? Porque o correio eletrónico tem de continuar sempre a funcionar, mesmo com servidores antigos. Um remetente não pode saber se um destinatário deveria ter TLS. Isto torna possíveis dois ataques:

1. Downgrade. Alguém que consegue alterar o tráfego pelo caminho remove a palavra STARTTLS da resposta do destinatário. O remetente pensa que não há encriptação e entrega sem encriptar. O atacante lê a mensagem.
2. MX falso. Alguém que consegue falsificar respostas de DNS indica um servidor próprio como MX. Como o certificado não é verificado, o remetente não dá por nada.

Atualmente, quase todos os grandes servidores de correio encriptam, e o Gmail exige que os remetentes utilizem TLS (lição 5.3). Mas “geralmente encriptado” é diferente de “sempre e com o servidor correto”. Para isso existem duas soluções: MTA-STS e DANE. Ambas são configuradas pelo destinatário: com elas, informa que o correio destinado ao seu domínio deve ser sempre encriptado, junto de um servidor com um certificado válido.

MTA-STS: política através de uma página web

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) funciona com duas componentes.

Um registo TXT que indica que existe uma política:

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20261108T120000;"

E um ficheiro de política num local fixo, através de https com um certificado válido:

https://mta-sts.example.com/.well-known/mta-sts.txt

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

O aspeto inteligente: um remetente retém a política em memória durante o período definido em max_age. Um atacante que, mais tarde, remova a palavra STARTTLS ou indique um MX falso é então detetado: a política indica que a encriptação é obrigatória e quais os servidores válidos. Na primeiríssima ligação (antes de a política ser conhecida), o MTA-STS não protege; esse é o ponto fraco conhecido.

Um exemplo real é o gmail.com: o registo TXT _mta-sts.gmail.com existe, e o ficheiro de política em https://mta-sts.gmail.com/.well-known/mta-sts.txt está definido em mode: enforce.

TLS-RPT: relatórios sobre falhas de encriptação

Com o MTA-STS em enforce, o correio pode ficar retido caso haja algum problema com o seu certificado. Convém saber disso. Para isso existe o TLS-RPT (RFC 8460):

_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrapport@example.com"

Os remetentes que suportam TLS-RPT (entre outros, Google e Microsoft) enviam então diariamente um relatório em formato JSON: quantas ligações foram bem-sucedidas e quais falharam, com o motivo (por exemplo, um certificado expirado ou um nome que não consta da política). Tal como acontece com os relatórios DMARC (lição 4.5), pode fazer com que esses relatórios sejam processados por um serviço de relatórios.

Ordem de implementação: primeiro o TLS-RPT, depois o MTA-STS em testing, algumas semanas a ler relatórios, e só depois o enforce. Isto assemelha-se à linha de recomendação do DMARC: primeiro observar, depois tornar rigoroso.

DANE: o certificado no DNS, protegido com DNSSEC

O DANE (DNS-based Authentication of Named Entities) aborda a questão de forma diferente. Coloca-se no DNS um registo TLSA para cada servidor MX, com uma impressão digital do certificado ou da chave:

_25._tcp.mx1.example.com.  3600  IN  TLSA  3 1 1 0d5a5c8f3d8aab82bba32bf8d711fa2433e4fe5fa4828b0443364d3ab5cdc1d5

_25._tcp significa: para SMTP na porta 25. Os três números indicam como o valor deve ser interpretado. Para servidores de correio, 3 1 1 é o mais utilizado: “esta é a impressão digital SHA-256 da chave pública exatamente deste servidor”. Também ocorre 2 1 1: nesse caso, consta a impressão digital de um certificado intermédio.

Um remetente que suporte DANE vê o registo TLSA, exige encriptação e verifica se o certificado do servidor corresponde. Se não corresponder, não entrega.

Porque é que o DANE é seguro contra respostas DNS falsificadas? Porque só funciona com DNSSEC (curso de DNS, lição 8.1). Sem uma cadeia DNSSEC válida, os registos TLSA são ignorados. Esse é precisamente o limiar: tanto o seu domínio (para o MX) como a zona do servidor de correio têm de estar assinados.

O DANE não tem uma fraqueza de “primeira vez” como o MTA-STS, e é muito utilizado nos Países Baixos e na Alemanha. O internet.nl testa isso. A Microsoft suporta DANE para correio recebido no Exchange Online. Também os servidores MX do internet.nl têm registos TLSA.

Cuidado: se substituir o certificado de um servidor de correio com DANE por uma nova chave, o registo TLSA tem de ser alterado em conjunto, e previamente: primeiro adicionar o novo registo, aguardar até o TTL expirar, só depois colocar a nova chave em utilização. Caso contrário, os remetentes com DANE recusam o seu correio. Com 3 1 1, isso só é relevante se a chave mudar, não em cada renovação com a mesma chave.

MTA-STS ou DANE?

Pode utilizá-los em conjunto. A RFC 8461 indica que um remetente que suporte DANE dá prioridade ao DANE caso existam registos TLSA válidos.

Quem trata disto?

Isto configura-se para o correio recebido no seu domínio. Se o seu correio estiver alojado numa empresa de hosting ou serviço de correio, depende dessa entidade:

• O DANE só é possível se o fornecedor publicar registos TLSA para os seus servidores de correio e o seu domínio tiver DNSSEC. No WebOké, por exemplo, pode ativar o DANE no mesmo local onde ativa o DNSSEC (consulte o artigo do internet.nl abaixo); noutros fornecedores funciona de forma semelhante ou já está definido por omissão.
• O MTA-STS por vezes pode ser configurado por si próprio, mas nesse caso mta-sts.example.com tem de ser um sítio web com um certificado válido e tem de conhecer os nomes MX do seu fornecedor.
• O TLS-RPT pode sempre ser configurado por si próprio: é apenas um registo TXT com um endereço de relatório.

Para o seu correio de saída, não precisa de fazer nada: é o servidor do seu fornecedor que determina se respeita o MTA-STS e o DANE dos destinatários.

Resumo

• Entre servidores de correio, o TLS é, por omissão, oportunista: encriptado quando possível, sem verificação rigorosa do certificado. Isto torna possíveis o downgrade e o MX falso.
• MTA-STS: TXT _mta-sts mais ficheiro de política em https://mta-sts.<domínio>/.well-known/mta-sts.txt; modo testing ou enforce.
• TLS-RPT: TXT _smtp._tls com um endereço de relatório, para relatórios diários sobre falhas de encriptação.
• DANE: registo TLSA em _25._tcp.<servidor-mx>, só funciona com DNSSEC e protege também a primeira ligação.
• Implemente como o DMARC: primeiro relatórios (TLS-RPT, testing), depois rigor.

Quiz

Exercício

Exercício Z5.4: Consultar MTA-STS, TLS-RPT e DANE. Consulte, para gmail.com, o registo MTA-STS e o registo TLS-RPT, abra o ficheiro de política e indique o modo (enforce, testing ou none). Em seguida, consulte, num servidor MX de internet.nl, o registo TLSA em _25._tcp.<servidor-mx> e indique os primeiros três números de um dos registos. Opcional: as mesmas perguntas para o seu próprio domínio (nesse caso, a resposta pode ser “nenhum”). O programa consulta tudo em tempo real e compara.

Para saber mais

Os passos descritos nestes artigos aplicam-se aos painéis do WebOké; noutros fornecedores funciona de forma semelhante.

• Lista de verificação do internet.nl
• O que é o DNSSEC?
• Curso gratuito de DNS 8.1: DNSSEC em linguagem simples
• internet.nl, teste o seu email (teste independente de STARTTLS, DANE e muito mais): https://internet.nl/
• RFC 8461 (MTA-STS), RFC 8460 (TLS-RPT), RFC 7672 (DANE para SMTP)