Como uma tecnologia de comunicação digital, o e-mail continua a dominar e crescer em uso. Em meu post anterior , destaquei muitas de suas virtudes, mas também aludi a algumas fraquezas que a maioria dos usuários desconhece.

Nesta postagem, exploraremos esses pontos fracos com mais detalhes e, especificamente, como o e-mail é transmitido entre os servidores. Também destacaremos como esses pontos fracos podem ser resolvidos com maior adoção de extensões estabelecidas para os protocolos de e-mail tradicionais (por exemplo, DANE).

Como sempre, este artigo é baseado em minha pesquisa e prática pessoal no assunto, mas compartilhar conhecimento é uma colaboração, então, por favor, forneça comentários ou feedback.

Introdução

Para facilitar o entendimento, destacarei três fases de alto nível de como as conexões entre os servidores de correio são estabelecidas.

Descoberta do servidor de email do destinatário , o processo de descobrir qual servidor de email deve aceitar email para um determinado domínio de destinatário.

Conexão com o servidor de correio do destinatário, tendo identificado o servidor de correio correto, o processo de conexão a ele e proteção da conexão com criptografia adequada (também conhecida como TLS).

Verificando se o servidor de e-mail do destinatário é realmente o correto, podemos ter certeza de que estabelecemos uma conexão segura com o servidor legítimo do domínio do destinatário.

Descoberta do servidor de correio do destinatário

Isso é mais comumente obtido por meio de uma pesquisa de DNS dos registros MX (Mail Exchange) que apontam para um ou mais endereços IP de servidores de email destinados a receber emails para o domínio do destinatário. No entanto existem outros mecanismos como MTA-STS, registros SRV ou mesmo registros A. Abordaremos alguns elementos do MTA-STS mais abaixo, mas não as abordagens de registro SRV/A (embora eles compartilhem os mesmos pontos fracos).

A descoberta de servidores de e-mail depende do DNS , e a grande maioria das consultas DNS ainda depende de pacotes UDP e, portanto, não têm conexão nem são criptografadas, tornando relativamente fácil interceptar e injetar respostas falsificadas.

Embora existam implementações de DNS que usam TCP, TLS e até DNS sobre HTTPS , elas são bastante incomuns, mas reduzem o potencial de interceptação e injeção entre cliente e servidor.

Embora a implantação do TCP/TLS se concentre em melhorar ou proteger a conexão, eles próprios não fornecem um mecanismo para garantir que os dados, as respostas às pesquisas de DNS, sejam genuínos e não tenham sido adulterados.

É aqui que entra o DNSSEC , ele fornece uma abordagem de assinatura digital ancorada na confiança que garante que todas as respostas DNS para domínios habilitados para DNSSEC possam ser validadas criptograficamente como genuínas e autorizadas.

E o DANE?

• O DANE requer DNSSEC para todas as pesquisas de DNS, o que atenua esse risco com sucesso.

• O MTA-STS publica os servidores de correio, com autoridade para um domínio, listando-os em um arquivo de política MTA-STS hospedado em um servidor da web. Embora a conexão com o próprio servidor da web possa ser HTTPS (com validação de certificado), ela não requer que a pesquisa de DNS desse servidor da web seja segura.
• MTA-STS não exige o uso de DNSSEC, na verdade, meu entendimento é que um de seus 'recursos de design' era que ele não dependia de DNSSEC.

• A descoberta de um servidor de correio de domínios destinatários depende do DNS, que sem o DNSSEC não tem segurança para garantir as respostas recebidas.
• O DANE exige o uso de DNSSEC, portanto, como uma extensão do SMTP, é o mecanismo mais eficaz para fornecer proteção contra esse risco.
• O MTA-STS não exige o uso de DNSSEC e, apesar de hospedar a política em um servidor HTTPS protegido, ainda depende de uma pesquisa de DNS tradicional.
• No entanto, o MTA-STS poderia ser implantado com DNSSEC, o que reduziria muito esse risco. Esta seria minha recomendação se você estiver no processo de implantação do MTA-STS.

O mundo mudou para HTTPS no que pareceu um piscar de olhos. Hoje em dia, é muito incomum encontrar qualquer site que não suporte HTTPS (mesmo aqueles que não aceitam os dados do seu cartão de crédito). No entanto, o e-mail não viu a mesma mudança de etapa na segurança e ainda depende do que chamamos de “TLS oportunista”. No TLS Oportunista, os servidores primeiro farão uma conexão insegura e, em seguida, tentarão negociar e atualizar a conexão para TLS, mas continuarão felizes sem o TLS se, por qualquer motivo, não puderem concordar.

O verdadeiro problema aqui é que “TLS Oportunista” inicialmente abre uma conexão insegura e a atualiza para TLS (iniciada pelo método STARTTLS). Portanto, é relativamente fácil interceptar tal conexão e inibir a atualização para TLS mascarando o suporte STARTTLS do servidor remoto. Os servidores de e-mail TLS oportunistas continuarão a troca de e-mails sem nenhum cuidado ou consideração. Pior ainda, nem o remetente nem os destinatários estariam remotamente cientes de que isso aconteceu.

Ambas as partes em uma conexão TLS utilizam certificados PKI que também podem ser usados ​​para fornecer níveis adicionais de confiança de que as partes são realmente quem dizem ser e verificáveis ​​independentemente por meio de uma âncora de confiança . No entanto, dada a facilidade de obter certificados de provedores como o LetsEncrypt, isso se torna menos confiável.

Na prática, a grande maioria dos servidores de e-mail oferece suporte a alguma forma de TLS e, portanto, há uma probabilidade muito alta de que seu e-mail tenha sido criptografado ao atravessar a Internet até seu destino. No entanto, ele não aborda o risco de um ataque MITM mascarar o suporte TLS e permitir conexões não criptografadas.

E o MTA-STS?

• O MTA-STS aborda esse risco (e supondo que você não esteja no modo de 'teste') exigindo implicitamente que uma conexão TLS seja estabelecida para a troca de e-mail.

• O DANE impõe o requisito implícito para uma conexão TLS e, portanto, reduz esse risco.

• TLS oportunista depende de uma conexão não criptografada para estabelecer a possibilidade de uma atualização para TLS e, portanto, é vulnerável a um ataque MITM.
• Tanto o DANE quanto o MTA-STS exigem implicitamente uma conexão TLS antes que o e-mail seja trocado, portanto, são eficazes para garantir que pelo menos uma conexão TLS básica seja estabelecida.
• O TLS sozinho não é suficiente para sugerir que uma conexão está suficientemente protegida/criptografada. Muitos dos protocolos e conjuntos de cifras implementados no TLS são considerados inseguros (forçável bruto). Este é um tópico completo em si que abordaremos em um artigo posterior.

Esta é sem dúvida uma etapa no processo de estabelecimento de uma conexão segura entre os servidores de correio. No entanto, na minha opinião, é um elemento tão crítico que merece sua própria seção.

Reconhecendo a dependência das fases anteriores, torna-se essencial que possamos validar ainda mais se o servidor ao qual estamos nos conectando é de fato o servidor autoritativo para o domínio dos destinatários. A primeira fase descrevia o estabelecimento de uma conexão TLS que pode ou não incluir a Verificação de Certificado. No entanto, em geral, tudo o que a Verificação de Certificado normalmente faz é validar se o nome do host fornecido corresponde ao nome do host detalhado no certificado no servidor remoto e, opcionalmente, se ele pode ser vinculado à âncora de confiança.

A DANE dá um passo adiante ao publicar um registro TLSA protegido por DNSSEC que contém uma impressão digital (e método de validação) para o certificado de servidores de correio fornecido. Isso fornece uma validação confiável e definitiva que garante categoricamente que o servidor ao qual você se conecta está apresentando o certificado específico reconhecido pelo administrador do DNS.

E o DANE?

• A validação do certificado dos servidores em relação a um registro TLSA protegido por DNSSEC é inerente ao DANE e fornece o selo final de aprovação para garantir a conexão.

• O MTA-STS não vai tão longe, seu objetivo é garantir que uma conexão TLS seja obrigatória e não se estenda à validação da autoridade dos servidores de correio.

Na minha opinião, não há razão racional para que essas deficiências permaneçam sem mitigação na maioria dos provedores de correio. A tecnologia existe para resolvê-los e é relativamente fácil de implantar atualmente. Minha suposição é que a falta de conscientização dos consumidores remove muito do incentivo para os provedores de correio implementarem essas tecnologias.

O MTA-STS fornece algumas melhorias importantes para os problemas de TLS oportunista, mas não vai longe o suficiente para resolver todos os pontos fracos. Adicionar DNSSEC ao MTA-STS reduz alguns dos riscos e seria minha recomendação (se o DANE não for uma opção para você).

DANE, no entanto, fornece uma solução abrangente para os pontos fracos discutidos neste artigo. Se você está considerando tanto o MTA-STS quanto o DANE, mas deseja escolher apenas um, o DANE seria minha recomendação.

Existem aproximadamente 365 milhões de nomes de domínio registrados em todo o mundo e apenas 3,7 milhões de domínios implantaram o DANE (aproximadamente 1%).

Se olharmos para os maiores provedores de e-mail, notamos que o Gmail implantou o MTA-STS, mas ainda não implantou o DANE ou mesmo o DNSSEC.

Da mesma forma, a Microsoft implantou o MTA-STS no Exchange Online este ano e anunciou sua intenção de oferecer DANE no futuro, mas é provável que demore mais alguns anos até que eles ofereçam suporte tanto de saída quanto de entrada.