Autenticação do email - Email authentication
A autenticação ou validação de e- mail é uma coleção de técnicas destinadas a fornecer informações verificáveis sobre a origem das mensagens de e-mail, validando a propriedade do domínio de quaisquer agentes de transferência de mensagens (MTA) que participaram da transferência e, possivelmente, da modificação de uma mensagem.
A base original do e-mail da Internet, Simple Mail Transfer Protocol (SMTP), não tem esse recurso, então endereços de remetentes forjados em e-mails (uma prática conhecida como spoofing de e-mail ) têm sido amplamente usados em phishing , spam de e-mail e vários tipos de fraude. Para combater isso, muitas propostas concorrentes de autenticação de e-mail foram desenvolvidas, mas apenas recentemente três foram amplamente adotadas - SPF , DKIM e DMARC . Os resultados dessa validação podem ser usados na filtragem automática de e-mail ou podem ajudar os destinatários a selecionar uma ação apropriada.
Este artigo não cobre a autenticação do usuário para envio e recuperação de e-mail.
Justificativa
No início da década de 1980, quando o protocolo SMTP ( Simple Mail Transfer Protocol ) foi projetado, ele não permitia nenhuma verificação real do usuário ou sistema de envio. Isso não era um problema enquanto os sistemas de e-mail eram administrados por empresas e universidades confiáveis, mas desde a comercialização da Internet no início dos anos 1990, spam , phishing e outros crimes envolvem cada vez mais e-mail.
A autenticação de e-mail é uma primeira etapa necessária para identificar a origem das mensagens e, assim, tornar as políticas e leis mais aplicáveis.
Basear-se na propriedade do domínio é uma postura que surgiu no início de 2000. Implica uma autenticação de baixa granularidade, uma vez que os domínios aparecem na parte direita dos endereços de e-mail, após o símbolo de arroba . A autenticação refinada, no nível do usuário, pode ser obtida por outros meios, como Pretty Good Privacy e S / MIME . Atualmente, a identidade digital precisa ser gerenciada por cada indivíduo.
Uma razão excelente para autenticação de e-mail é a capacidade de automatizar a filtragem de e-mail nos servidores de recebimento. Dessa forma, as mensagens falsificadas podem ser rejeitadas antes de chegarem à caixa de entrada do usuário. Embora os protocolos se esforcem para criar maneiras de bloquear e-mails suspeitos de maneira confiável, os indicadores de segurança podem marcar mensagens não autenticadas que ainda chegam à caixa de entrada. Um estudo de 2018 mostra que os indicadores de segurança podem reduzir a taxa de cliques em mais de dez pontos, 48,9% a 37,2% dos usuários que abrem mensagens falsificadas.
Natureza do problema
O SMTP define o transporte da mensagem , não o conteúdo da mensagem . Assim, ele define o envelope de correio e seus parâmetros, como o remetente do envelope , mas não o cabeçalho (exceto as informações de rastreamento ) nem o próprio corpo da mensagem. O STD 10 e o RFC 5321 definem o SMTP (o envelope), enquanto o STD 11 e o RFC 5322 definem a mensagem (cabeçalho e corpo), formalmente denominado Formato de Mensagem da Internet .
O SMTP define as informações de rastreamento de uma mensagem, que são salvas no cabeçalho usando os dois campos a seguir:
- Recebido : quando um servidor SMTP aceita uma mensagem, ele insere este registro de rastreamento no topo do cabeçalho (do último ao primeiro).
- Caminho de retorno : quando o servidor SMTP de entrega faz a entrega final de uma mensagem, ele insere este campo no topo do cabeçalho.
Um agente de usuário de correio (MUA) conhece o servidor SMTP de correio de saída a partir de sua configuração. Um MTA (ou um servidor de retransmissão) normalmente determina a qual servidor se conectar, procurando o registro de recurso DNS MX (Mail eXchange) para o nome de domínio de cada destinatário
O caminho descrito abaixo pode ser reconstruído com base nos campos de cabeçalho de rastreamento que cada host adiciona ao topo do cabeçalho quando recebe a mensagem:
Return-Path: <author@example.com>
Received: from D.example.org by E.example.org with SMTP; Tue, 05 Feb 2013 11:45:02 -0500
Received: from C.example.net by D.example.org with SMTP; Tue, 05 Feb 2013 11:45:02 -0500
Received: from B.example.com (b.example.com [192.0.2.1])
by C.example.net (which is me) with ESMTP id 936ADB8838C
for <different-recipient@example.net>; Tue, 05 Feb 2013 08:44:50 -0800 (PST)
Received: from A.example.com by B.example.com with SMTP; Tue, 05 Feb 2013 17:44:47 +0100
Received: from [192.0.2.27] by A.example.com with SMTP; Tue, 05 Feb 2013 17:44:42 +0100
É importante perceber que o destinatário geralmente confia nas primeiras linhas na parte superior do cabeçalho. Na verdade, essas linhas são escritas por máquinas no Domínio de Gerenciamento Administrativo ( ADMD ) do destinatário , que agem de acordo com seu mandato explícito. Por outro lado, as linhas que provam o envolvimento de A e B , bem como do autor suposta MUA poderia ser uma falsificação criada por C . O Received:campo mostrado acima é uma parte do cabeçalho que marcou época. O Return-Path:é escrito por E , o agente de entrega de correio (MDA), com base no envelope da mensagem . Campos de rastreamento adicionais, projetados para autenticação de email, podem preencher a parte superior do cabeçalho.
Normalmente, as mensagens enviadas pelo ADMD de um autor vão diretamente para o MX de destino (ou seja, B → D nas figuras). O ADMD do remetente pode adicionar tokens de autenticação apenas se a mensagem passar por suas caixas. Os casos mais comuns podem ser esquematizados da seguinte forma:
Envio de dentro da rede da ADMD (MUA 1)
- O MSA do ADMD autentica o usuário, seja com base em seu endereço IP ou algum outro meio de autenticação SMTP. Dependendo do endereço do destinatário, a mensagem pode seguir o caminho normal ou passar por uma lista de distribuição ou serviço de encaminhamento. B pode ser um proxy SMTP de saída ou um host inteligente .
- Se a rede local não bloquear as conexões de saída da porta 25, o usuário pode implantar algum software "direto para mx". Normalmente, os zumbis e outros hosts maliciosos se comportam dessa maneira.
- Se o MUA estiver mal configurado, ele também pode usar um relé diferente, como um relé aberto ultrapassado , que geralmente não autentica o usuário.
Usuário de roaming (MUA 2)
- Na maioria das vezes, ainda é possível usar o próprio ADMD MSA.
- As conexões de saída para a porta 25 podem ser interceptadas e encapsuladas em um proxy transparente.
- Um MUA pode ser configurado para usar uma retransmissão SMTP que o provedor de rede local oferece como bônus.
Usuário desconectado
- Um e-card pode enviar e- mail em nome de um cliente que digitou endereços de e-mail no teclado local; alguns formulários da web podem funcionar de maneira semelhante.
Notas de seção
Métodos de autenticação em uso generalizado
SPF
O SPF permite que o destinatário verifique se um e-mail alegadamente proveniente de um domínio específico vem de um endereço IP autorizado pelos administradores desse domínio. Normalmente, um administrador de domínio autoriza os endereços IP usados por seus próprios MTAs de saída, incluindo qualquer proxy ou host inteligente.
O endereço IP do MTA remetente é garantido como válido pelo Transmission Control Protocol , uma vez que estabelece a conexão verificando se o host remoto está acessível. O servidor de recebimento de email recebe o comando HELO SMTP logo após a configuração da conexão e um Mail from:no início de cada mensagem. Ambos podem conter um nome de domínio. O verificador SPF consulta o Sistema de Nomes de Domínio (DNS) em busca de um registro SPF correspondente, que, se existir, especificará os endereços IP autorizados pelo administrador desse domínio. O resultado pode ser "aprovado", "reprovado" ou algum resultado intermediário - e os sistemas geralmente levam isso em consideração em sua filtragem anti-spam.
DKIM
.png)
O DKIM verifica o conteúdo da mensagem , implantando assinaturas digitais . Em vez de usar certificados digitais, as chaves para verificação de assinatura são distribuídas por meio do DNS. Dessa forma, uma mensagem é associada a um nome de domínio.
Um administrador de domínio compatível com DKIM gera um ou mais pares de chaves assimétricas , entrega as chaves privadas ao MTA de assinatura e publica as chaves públicas no DNS. Os rótulos DNS são estruturados como selector._domainkey.example.com, onde seletor identifica o par de chaves e _domainkeyé uma palavra-chave fixa, seguida pelo nome do domínio de assinatura para que a publicação ocorra sob a autoridade do ADMD desse domínio. Antes de injetar uma mensagem no sistema de transporte SMTP, o MTA de assinatura cria uma assinatura digital que cobre os campos selecionados do cabeçalho e do corpo (ou apenas seu início). A assinatura deve cobrir campos de cabeçalho substantivas, tais como From:, To:, Date:, e Subject:, em seguida, é adicionado ao próprio cabeçalho da mensagem, como um campo de rastreamento. Qualquer número de retransmissões pode receber e encaminhar a mensagem e, a cada salto, a assinatura pode ser verificada recuperando a chave pública do DNS. Desde que os relés intermediários não modifiquem as partes assinadas de uma mensagem, suas assinaturas DKIM permanecem válidas.
DMARC
DMARC permite a especificação de uma política para mensagens autenticadas. Ele é baseado em dois mecanismos existentes, Sender Policy Framework (SPF) e DomainKeys Identified Mail (DKIM).
Ele permite que o proprietário administrativo de um domínio publique uma política em seus registros DNS para especificar qual mecanismo (DKIM, SPF ou ambos) é empregado ao enviar e-mail daquele domínio; como verificar o From:campo apresentado aos usuários finais; como o receptor deve lidar com as falhas - e um mecanismo de relatório para as ações realizadas de acordo com essas políticas.
Outros métodos
Vários outros métodos foram propostos, mas agora estão obsoletos ou ainda não ganharam suporte generalizado. Estes incluem ID do Remetente , Validação de Servidor Certificado , DomainKeys e os seguintes:
ADSP
O ADSP permitiu a especificação de uma política para mensagens assinadas pelo domínio do autor. Uma mensagem precisava passar pela autenticação DKIM primeiro, então o ADSP poderia exigir um tratamento punitivo se a mensagem não fosse assinada pelo (s) domínio (s) do autor - conforme o From:campo do cabeçalho.
A ADSP foi rebaixada a histórica em novembro de 2013.
VBR
O VBR adiciona um comprovante a uma identidade já autenticada. Este método requer algumas autoridades reconhecidas globalmente que certificam a reputação de domínios.
Um remetente pode solicitar uma referência em uma autoridade de vouching. A referência, se aceita, é publicada na filial DNS gerenciada por essa autoridade. Um remetente com garantia deve adicionar um VBR-Info:campo de cabeçalho às mensagens que envia. Ele também deve adicionar uma assinatura DKIM ou usar algum outro método de autenticação, como SPF. Um receptor, após validar a identidade do remetente, pode verificar o vouch reivindicado VBR-Info:procurando a referência.
iprev
Os aplicativos devem evitar o uso desse método como meio de autenticação. No entanto, muitas vezes é realizada e seus resultados, se houver, escritos no Received:campo de cabeçalho além das informações de TCP exigidas pela especificação SMTP.
O reverso do IP, confirmado procurando o endereço IP do nome recém-encontrado, é apenas uma indicação de que o IP foi configurado corretamente no DNS. A resolução reversa de um intervalo de endereços IP pode ser delegada ao ADMD que os usa ou pode permanecer gerenciada pelo provedor de rede. No último caso, nenhuma identidade útil relacionada à mensagem pode ser obtida.
DNSWL
Pesquisar uma DNSWL (lista de permissões baseada em DNS) pode fornecer uma avaliação do remetente, possivelmente incluindo sua identificação.
Resultados de autenticação
O RFC 8601 define um campo de cabeçalho de rastreamento em Authentication-Results:que um destinatário pode registrar os resultados das verificações de autenticação de e-mail que realizou. Vários resultados para vários métodos podem ser relatados no mesmo campo, separados por ponto-e-vírgula e agrupados conforme apropriado.
Por exemplo, o campo a seguir foi supostamente escrito por receiver.example.orge relata os resultados SPF e DKIM :
Authentication-Results: receiver.example.org;
spf=pass smtp.mailfrom=example.com;
dkim=pass header.i=@example.com
O primeiro token após o nome do campo ,,receiver.example.org é o ID do servidor de autenticação, um token conhecido como authserv-id . Um receptor com suporte a RFC 8601 é responsável por remover (ou renomear) qualquer cabeçalho falso que alega pertencer ao seu domínio para que os filtros downstream não sejam confundidos. No entanto, esses filtros ainda precisam ser configurados, pois precisam saber quais identidades o domínio pode usar.
Para um Mail User Agent (MUA), é um pouco mais difícil aprender em quais identidades ele pode confiar. Uma vez que os usuários podem receber e-mail de vários domínios - por exemplo, se eles têm vários endereços de e-mail - qualquer um desses domínios pode deixar os Authentication-Results:campos passarem porque parecem neutros. Dessa forma, um remetente mal-intencionado pode forjar um authserv-id em que o usuário confiaria se a mensagem chegasse de um domínio diferente. Um legítimo Authentication-Results:normalmente aparece logo acima de um Received:campo do mesmo domínio do qual a mensagem foi retransmitida. Received:Campos adicionais podem aparecer entre esse e o topo do cabeçalho, pois a mensagem foi transferida internamente entre servidores pertencentes ao mesmo ADMD confiável.
A Internet Assigned Numbers Authority mantém um registro dos parâmetros de autenticação de email . No entanto, nem todos os parâmetros precisam ser registrados. Por exemplo, pode haver valores de "política" locais projetados apenas para uso interno de um site, que correspondem à configuração local e não precisam de registro.
Veja também
- DMARC - Sistema para prevenir fraude por e-mail
- Criptografia de e-mail
- Spoofing de e-mail - Criação de spam de e-mail ou mensagens de phishing com identidade ou endereço de remetente forjado
- Ident - protocolo de Internet que ajuda a identificar o usuário de uma conexão TCP específica
- Mensagens seguras