A segurança é uma das nossas principais prioridades, com privacidade. Trabalhamos duro para fornecer aos nossos usuários a experiência mais segura e privada ao usar o Mailfence. Muitos usuários, como jornalistas ou dissidentes, usam nosso serviço para comunicações confidenciais. Muitas vezes são alvo de ameaças persistentes avançadas. Ao longo dos últimos anos, lançamos vários novos recursos para melhorar os liberada vários novos recursos para melhorar a segurança de todos os usuários do Mailfence.
Do DANE ao MTA-STS, WKD e VKS, vamos nos concentrar em nossas melhorias de segurança para manter seus dados seguros.
DANE e MTA-STSPor que você quer
Autenticação de Entidades Nomeadas (DANE) baseada em DNS e Segurança de Transporte Estrita do Agente de Transporte de Correio (MTA-STS) são dois protocolos separados que abordam principalmente o mesmo problema, comumente conhecido como ataque de rebaixamento. Simplificando, um invasor pode remover a camada de criptografia durante o transporte de e-mails. Portanto, é importante ter um mecanismo que garanta que a criptografia de transporte permaneça intacta quando os e-mails forem de uma conta para outra. Nos primórdios da Internet, os servidores de e-mail enviavam e recebiam e-mails em texto simples — sem criptografia de camada de transporte. Isso significava que qualquer pessoa que monitorasse a rede poderia ler ou modificar a mensagem. Depois de TLS chegada, o padrão de e-mail foi adaptado para incluir criptografia de transporte se os servidores de envio e recebimento o suportarem. No entanto, um invasor ainda pode enganar o servidor de envio para passar e-mail em texto simples anunciando erroneamente que o servidor de recebimento não oferece suporte à criptografia da camada de transporte.
Como funciona
MTA-STS é um protocolo que garante a entrega de e-mail usando criptografia de transporte (não confundir com criptografia de ponta a ponta) se o servidor de recebimento o suportar. O servidor de correio de envio procura e armazena em cache a política MTA-STS do servidor de correio de recebimento. Dependendo da política do MTA-STS do servidor receptor, ele recusará qualquer tentativa de remover a camada de criptografia de transporte. O servidor de envio depende de um longo tempo de cache para evitar ataques transitórios. A desvantagem, no entanto, é que cada servidor de e-mail deve manter seu próprio cache. Além disso, um proprietário de domínio pode definir, mas não impor uma política MTA-STS.DANE usa registros DNS para informar outros servidores de e-mail sobre o suporte à criptografia TLS. Além disso, ele diz ao servidor receptor para esperar um certo certificado ao se conectar ao servidor de envio — defendendo-se contra invasores na posse de um certificado TLS válido do servidor de envio. No entanto, ele depende da segurança do sistema DNS, o que significa que requer Extensões de Segurança DNS (DNSSEC) — resultando em adoção limitada (isto é agora mudando). O suporte ao DNSSEC (como pré-requisito para suporte ao DANE) também traz vantagens de segurança adicionais. Alguns exemplos incluem proteção contra DNS envenenamento de cache ataque e para domínios personalizados que usam os registros MX do Mailfence, especialmente se o domínio personalizado implementar DNSSEC.MTA-STS e DANE têm seus prós e contras. Cada um deles pode proteger contra ataques de downgrade de criptografia de entrega de e-mail. Portanto, implementamos ambos para mailfence.com.
Descoberta e troca de chaves OpenPGP (WKD e VKS)
Ofertas de Mailfence OpenPGP criptografia e assinatura para e-mails. Temos sido interoperáveis com outros serviços compatíveis com OpenPGP desde o início e fornecemos aos nossos controle total sobre OpenPGP keys. No entanto, a descoberta e troca de chaves tem sido um desafio no ecossistema OpenPGP porque é difícil saber se as chaves que você recebe de um servidor de chave pública devem ser confiáveis.
Diretório de chave da Web (WKD)
Mailfence agora suporta uma nova abordagem, chamada Web Key Directory (WKD), que usa a web para permitir que um domínio sirva suas próprias chaves via HTTPS. Isso significa que, quando você generar um OpenPGP key par ou importá-lo em seu armazenamento de chaves de conta do Mailfence, a respectiva chave pública (incluindo endereço de e-mail e nome) estará disponível publicamente em nosso servidor Web Key Directory se:· O endereço de e-mail associado é baseado no nome de domínio mailfence.com.· Uma associação do endereço de e-mail do usuário é feita com a chave User ID. Um ícone de chave ao lado do endereço De no compositor de mensagens o representa.· A chave está associada ao endereço principal ou alias da conta do Mailfence.A chave pública é servida apenas para e com o pacote de ID de usuário consultado para não expor outros pacotes de ID de usuário associados (por motivos de privacidade e anti-spam). Nós não suportamos Web Key Service (WKS) protocolo. Os usuários também podem baixar chaves públicas OpenPGP de domínios externos (ou serviços) que suportam WKD em seu armazenamento de chaves de conta Mailfence. Domínio personalizado proprietário terá que configurá-lo para domínio próprio ou pode usar WKD como um serviço.
Validando o servidor de chaves (VKS)
No passado, usávamos o Synchronizing Key Server (SKS) pool. Após a aplicação do LGPD em 2018, estávamos procurando alternativas devido a preocupações conhecidas de privacidade de dados com o pool SKS (que acabou sendo fechado em 21-06-2021). Consideramos vários servidores de chave pública e, finalmente, acertamos com keys.openpgp.org. Você pode ler mais sobre eles aqui.Eles permitem que informações de identidade (ID do usuário: nome de exibição e endereço de e-mail) sejam distribuídas apenas com consentimento e também permitem sua remoção. Verifique seus política de privacidade para mais detalhes.Você pode encontrar chaves públicas usando o endereço de e-mail. Observe que as chaves sem ID de usuário (nome de exibição e/ou endereço de e-mail) atualmente não são processáveis do nosso lado. Planejamos abordar isso no futuro.
Ordem de pesquisa de chave
Nosso objetivo era usar um mecanismo de descoberta de chave que fornece:· Confirmação positiva da propriedade da chave / resistência ao vandalismo· Resistência à censura· Descentralização Não encontramos uma mídia que suporte todos os três pontos acima, então decidimos oferecer suporte a vários mecanismos. Quando um usuário procurando por uma chave pública, a plataforma Mailfence usa a seguinte ordem de pesquisa de chave:1 – Web Key Directory (WKD): o proprietário do domínio atua como uma âncora de confiança para confirmação positiva da propriedade da chave (através da TOFU modelo). 1 – Web Key Directory (WKD): o proprietário do domínio atua como um âncora de confiança para confirmação positiva da propriedade da chave (através do modelo TOFU). Se uma chave pública for encontrada, o processo de pesquisa de chave será interrompido.2 – Validating Key Server (VKS): a propriedade do endereço de e-mail é realizada via double opt-in validação. Não ser controlado/gerenciado por um proprietário de domínio de chave pública oferece um nível de resistência à censura.A validação de assinatura e a atualização do status da chave pública são sempre feitas usando o VKS (nenhuma ordem de pesquisa está envolvida).Ainda não encontramos um mecanismo adequado que ofereça o nível desejado de descentralização (um dos valores fundadores do OpenPGP) e continuamos atentos aos esforços em andamento nesse sentido.
Outros
- Começamos a aplicar a política DMARC dos remetentes. Você pode leia mais aquiComeçamos a usar o registro DNS CAA. Isso ajuda a evitar que as autoridades de certificação emitam um documento ilegítimo Mailfence certificado.Para ficar de olho nos problemas de conectividade TLS durante a entrega de e-mail, ficamos de olho nos relatórios enviados via TLSRPT standard.Para proteger nossos usuários contra ataques de falsificação de identidade e nosso serviço contra abusos, decidimos proibir a exclusão de endereços de alias baseados em nomes de domínio do Mailfence. Esta alteração será aplicada em 01-jan-2022. Consulte mais informação aqui.
- privado
- seguro
- contribuindo
- página de imprensa
