Encontre a modificação antes de culpar o gateway
Um gateway de segurança pode inspecionar ou transformar legitimamente e-mails enquanto complica o downstream DKIM verificação. A reescrita de URL, a substituição de anexos e os avisos do corpo são exemplos possíveis, mas a presença do gateway por si só não prova nada sobre uma assinatura com falha. Estabeleça qual representação entrou no gateway, qual saiu dele e onde a autenticação foi avaliada.
Nenhuma conta de gateway ou fluxo de mensagens foi acessado para este artigo. Porta de evidência original: mensagens brutas originais e modificadas, posicionamento do signatário e um teste de verificação antes e depois. Esses itens permanecem não coletados. O caso trabalhado é fictício. Qualquer alteração operacional deverá preservar os controles de segurança pretendidos e seguir o processo aprovado pelo proprietário.
Faça um inventário da sequência exata de processamento
Desenhe uma sequência desde a aceitação da mensagem até a autenticação, inspeção de ameaças, modificação de conteúdo, assinatura e entrega posterior. Um serviço pode combinar essas funções e vários gateways podem aparecer em uma rota. Registre a versão e o comportamento ativado somente quando compatível com a configuração real. Não presuma que um produto sempre verifica antes de reescrever ou que seu conector de saída sempre assina.
RFC 7960 descreve filtros de limite que removem conteúdo prejudicial, marcam suspeitas de spam ou alteram URLs. Também explica por que avaliar a autenticação após as modificações de um filtro pode produzir resultados diferentes. Estas são possibilidades arquitetônicas, não um veredicto sobre um inquilino específico. Um rastreamento de mensagens e cópias preservadas são necessários para conectar o mecanismo documentado a um incidente. Seção 3.2.5 RFC 7960
Determine o que a assinatura com falha cobriu
Para cada DKIM-Signature, preserve o domínio de assinatura d=, seletor s=, canonização c=, header list h= and any l= body-length value. The hash de corpo é calculado sobre a entrada do corpo canônico selecionado; a assinatura também cobre instâncias de cabeçalho especificadas. “O gateway alterou um cabeçalho” fica incompleto sem saber se aquela instância foi selecionada e se a canonização preservou a diferença. Seções 3.4–3.5 e 5.4 RFC 6376
A canonização relaxada tolera alterações específicas de espaços em branco e formatação de cabeçalho. Ele não trata edições arbitrárias de HTML, substituições de URL ou alterações de anexos como conteúdo equivalente. Por outro lado, um campo adicionado fora da cobertura selecionada não precisa invalidar uma assinatura existente. A duplicação e a assinatura excessiva de cabeçalhos podem complicar essa avaliação; portanto, compare as instâncias selecionadas em vez de apenas uma lista de nomes de campos exclusivos. Seções 3.4 e 5.4 RFC 6376
Compare mensagens brutas sem alterar as evidências
Use arquivos de mensagens brutas inalterados de pontos de captura aprovados. As capturas de tela renderizadas podem ocultar limites MIME , alterações de codificação e cabeçalhos dobrados. Salvar novamente uma mensagem por meio de um editor pode alterar os finais de linha ou a serialização, portanto, mantenha os originais e realize análises nas cópias. Registre o tempo de captura, a posição da rota e os hashes do arquivo para conectar cada amostra à etapa reivindicada.
Uma assinatura com falha posterior não estabelece que a assinatura era válida antes do gateway. RFC 6376 alerta que um verificador geralmente não pode inferir a validade anterior de uma assinatura inválida. O teste proposto, portanto, inclui a verificação da entrada e da saída preservadas, com a chave relevante e o contexto do verificador retidos. Caso contrário, um erro de assinatura preexistente poderá ser atribuído erroneamente ao gateway. RFC 6376 seção 4.2
Trabalhe com uma substituição de URL fictícia
Suponha que uma assinatura fictícia de autor-domínio seja verificada em uma mensagem de entrada bruta e cubra todo o seu corpo. Um gateway então substitui um URL em uma parte HTML MIME por um URL de proteção contra ameaças. A saída correspondente contém diferentes bytes de corpo canônicos e uma tentativa de verificação relata incompatibilidade de hash de corpo. Estas suposições formam um resultado de teste ilustrativo; nenhum teste desse tipo foi executado aqui.
Essa comparação apoia a conclusão restrita de que a substituição observada afetou o corpo coberto desta assinatura. Isso não implica que cada ação do gateway quebre todas as assinaturas ou que a proteção deva ser desativada. Uma assinatura adicional de gateway.example pode autenticar o tratamento da mensagem modificada por esse domínio, mas não reconstrói a assinatura do autor original nem se alinha automaticamente com um domínio de autor não relacionado. Seções 3.4 e 5.1 RFC 6376 Seção 5.3 RFC 9989
Mantenha os resultados de entrada e a verificação downstream distintos
Uma organização pode contar com a autenticação realizada no seu ingresso confiável antes das transformações de segurança interna. Preserve a identidade do avaliador e o limite de confiança por trás desse resultado. Um receptor downstream avaliando bytes modificados pode obter corretamente um resultado DKIM diferente. Copiando um Authentication-Results campo em uma mensagem, por si só, não torna esse campo confiável fora dos limites que o produziram. RFC 8601 seções 5 e 7
ARC podem realizar avaliações prévias através dos manipuladores participantes, mas a validação da cadeia e a confiança nesses manipuladores permanecem questões diferentes. RFC 8617 não faz ARC um mecanismo para restaurar uma assinatura DKIM antiga. Sua categoria publicada é Experimental; a proposta revisada para mover ARC para Histórico continua sendo um rascunho ativo. Não prometa que a ativação ARC fará com que todos os receptores downstream aceitem mensagens modificadas pelo gateway. Seções 5.2 e 9.3 RFC 8617 Status da proposta IETF
Coloque a assinatura legítima após as alterações pretendidas
Para mensagens de saída criadas em um domínio controlado pela organização, um design compatível pode colocar o signatário alinhado autorizado após as alterações finais do conteúdo legítimo. Verifique se as etapas posteriores não modificam o conteúdo coberto novamente. Um gateway não pode assinar legitimamente como domínio de um autor externo apenas porque retransmite a mensagem desse autor; a autorização de domínio relevante e a custódia da chave devem existir. RFC 6376 seção 5.1
O pacote de revisão deve indicar qual controle permanece ativo, qual ordem de processamento é proposta e como a verificação antes e depois será repetida. Não use cobertura corporal reduzida ou desvios gerais de autenticação apenas para produzir um indicador verde. Um teste autorizado bem-sucedido suportaria apenas suas rotas e formulários de mensagens amostrados. Pares brutos originais, posicionamento real do signatário e um resultado de verificação controlado ainda estão ausentes neste rascunho.