{"id":64167,"date":"2021-12-22T13:05:29","date_gmt":"2021-12-22T12:05:29","guid":{"rendered":"https:\/\/blog.mailfence.com\/mailfence-continua-melhorando-seguranca-para-seus-usuarios\/"},"modified":"2024-11-14T10:11:47","modified_gmt":"2024-11-14T09:11:47","slug":"mailfence-continua-melhorando-seguranca-para-seus-usuarios","status":"publish","type":"post","link":"https:\/\/blog.mailfence.com\/pt\/mailfence-continua-melhorando-seguranca-para-seus-usuarios\/","title":{"rendered":"Mailfence continua melhorando a seguran\u00e7a para seus usu\u00e1rios"},"content":{"rendered":"\n

A seguran\u00e7a \u00e9 uma das nossas principais prioridades, com privacidade. Trabalhamos duro para fornecer aos nossos usu\u00e1rios a experi\u00eancia mais segura e privada ao usar o Mailfence. Muitos usu\u00e1rios, como jornalistas ou dissidentes, usam nosso servi\u00e7o para comunica\u00e7\u00f5es confidenciais. Muitas vezes s\u00e3o alvo de amea\u00e7as persistentes avan\u00e7adas<\/a>. Ao longo dos \u00faltimos anos, lan\u00e7amos v\u00e1rios novos recursos para melhorar os liberada<\/a> v\u00e1rios novos recursos para melhorar a seguran\u00e7a de todos os usu\u00e1rios do Mailfence.<\/p>\n\n\n\n

Do DANE ao MTA-STS, WKD e VKS, vamos nos concentrar em nossas melhorias de seguran\u00e7a para manter seus dados seguros.<\/p>\n\n\n\n

<\/figure>\n\n\n\n

DANE e MTA-STSPor que voc\u00ea quer<\/h2>\n\n\n\n

Autentica\u00e7\u00e3o de Entidades Nomeadas (DANE) baseada em DNS e Seguran\u00e7a de Transporte Estrita do Agente de Transporte de Correio (MTA-STS) s\u00e3o 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, \u00e9 importante ter um mecanismo que garanta que a criptografia de transporte permane\u00e7a intacta quando os e-mails forem de uma conta para outra. Nos prim\u00f3rdios da Internet, os servidores de e-mail enviavam e recebiam e-mails em texto simples \u2014 sem criptografia de camada de transporte. Isso significava que qualquer pessoa que monitorasse a rede poderia ler ou modificar a mensagem. Depois de TLS<\/a> chegada, o padr\u00e3o 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\u00e3o oferece suporte \u00e0 criptografia da camada de transporte.<\/p>\n\n\n\n

Como funciona<\/h3>\n\n\n\n

MTA-STS \u00e9 um protocolo que garante a entrega de e-mail usando criptografia de transporte (n\u00e3o confundir com criptografia de ponta a ponta<\/a>) se o servidor de recebimento o suportar. O servidor de correio de envio procura e armazena em cache a pol\u00edtica MTA-STS do servidor de correio de recebimento. Dependendo da pol\u00edtica do MTA-STS do servidor receptor, ele recusar\u00e1 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\u00f3rios. A desvantagem, no entanto, \u00e9 que cada servidor de e-mail deve manter seu pr\u00f3prio cache. Al\u00e9m disso, um propriet\u00e1rio de dom\u00ednio pode definir, mas n\u00e3o impor uma pol\u00edtica MTA-STS.DANE usa registros DNS para informar outros servidores de e-mail sobre o suporte \u00e0 criptografia TLS. Al\u00e9m disso, ele diz ao servidor receptor para esperar um certo certificado ao se conectar ao servidor de envio \u2014 defendendo-se contra invasores na posse de um certificado TLS v\u00e1lido do servidor de envio. No entanto, ele depende da seguran\u00e7a do sistema DNS, o que significa que requer Extens\u00f5es de Seguran\u00e7a DNS (DNSSEC) \u2014 resultando em ado\u00e7\u00e3o limitada (isto \u00e9 agora mudando<\/a>). O suporte ao DNSSEC (como pr\u00e9-requisito para suporte ao DANE) tamb\u00e9m traz vantagens de seguran\u00e7a adicionais. Alguns exemplos incluem prote\u00e7\u00e3o contra DNS envenenamento de cache ataque e para dom\u00ednios personalizados que usam os registros MX do Mailfence, especialmente se o dom\u00ednio personalizado implementar DNSSEC.MTA-STS e DANE t\u00eam seus pr\u00f3s e contras. Cada um deles pode proteger contra ataques de downgrade de criptografia de entrega de e-mail. Portanto, implementamos ambos para mailfence.com.<\/strong><\/p>\n\n\n\n

Descoberta e troca de chaves OpenPGP (WKD e VKS)<\/h2>\n\n\n\n

Ofertas de Mailfence OpenPGP criptografia e assinatura<\/a> para e-mails. Temos sido interoper\u00e1veis com outros servi\u00e7os compat\u00edveis com OpenPGP desde o in\u00edcio e fornecemos aos nossos controle total sobre OpenPGP keys<\/a>. No entanto, a descoberta e troca de chaves tem sido um desafio no ecossistema OpenPGP porque \u00e9 dif\u00edcil saber se as chaves que voc\u00ea recebe de um servidor de chave p\u00fablica devem ser confi\u00e1veis. <\/p>\n\n\n\n

Diret\u00f3rio de chave da Web (WKD)<\/h2>\n\n\n\n

Mailfence agora suporta uma nova abordagem, chamada Web Key Directory (WKD)<\/a>, que usa a web para permitir que um dom\u00ednio sirva suas pr\u00f3prias chaves via HTTPS. Isso significa que, quando voc\u00ea generar um OpenPGP key par<\/a> ou import\u00e1-lo<\/a> em seu armazenamento de chaves de conta do Mailfence, a respectiva chave p\u00fablica (incluindo endere\u00e7o de e-mail e nome) estar\u00e1 dispon\u00edvel publicamente em nosso servidor Web Key Directory se:\u00b7 O endere\u00e7o de e-mail associado \u00e9 baseado no nome de dom\u00ednio mailfence.com.\u00b7  Uma associa\u00e7\u00e3o do endere\u00e7o de e-mail do usu\u00e1rio \u00e9 feita com a chave User ID<\/a>. Um \u00edcone de chave ao lado do endere\u00e7o De no compositor de mensagens o representa.\u00b7  A chave est\u00e1 associada ao endere\u00e7o principal ou alias da conta do Mailfence.A chave p\u00fablica \u00e9 servida apenas para e com o pacote de ID de usu\u00e1rio consultado para n\u00e3o expor outros pacotes de ID de usu\u00e1rio associados (por motivos de privacidade e anti-spam). N\u00f3s n\u00e3o suportamos Web Key Service (WKS)<\/a> protocolo. Os usu\u00e1rios tamb\u00e9m podem baixar chaves p\u00fablicas OpenPGP de dom\u00ednios externos (ou servi\u00e7os) que suportam WKD em seu armazenamento de chaves de conta Mailfence. Dom\u00ednio personalizado<\/a> propriet\u00e1rio ter\u00e1 que configur\u00e1-lo<\/a> para dom\u00ednio pr\u00f3prio ou pode usar WKD como um servi\u00e7o<\/a>. <\/p>\n\n\n\n

Validando o servidor de chaves (VKS)<\/h3>\n\n\n\n

No passado, us\u00e1vamos o Synchronizing Key Server (SKS<\/a>) pool<\/a>. Ap\u00f3s a aplica\u00e7\u00e3o do LGPD<\/a> em 2018, est\u00e1vamos procurando alternativas devido a preocupa\u00e7\u00f5es conhecidas de privacidade de dados com o pool SKS (que acabou sendo fechado em 21-06-2021<\/a>). Consideramos v\u00e1rios servidores de chave p\u00fablica e, finalmente, acertamos com keys.openpgp.org. Voc\u00ea pode ler mais sobre eles aqui<\/a>.Eles permitem que informa\u00e7\u00f5es de identidade (ID do usu\u00e1rio: nome de exibi\u00e7\u00e3o e endere\u00e7o de e-mail) sejam distribu\u00eddas apenas com consentimento e tamb\u00e9m permitem sua remo\u00e7\u00e3o. Verifique seus pol\u00edtica de privacidade<\/a> para mais detalhes.Voc\u00ea pode encontrar chaves p\u00fablicas usando o endere\u00e7o de e-mail. Observe que as chaves sem ID de usu\u00e1rio (nome de exibi\u00e7\u00e3o e\/ou endere\u00e7o de e-mail) atualmente n\u00e3o s\u00e3o process\u00e1veis do nosso lado. Planejamos abordar isso no futuro. <\/p>\n\n\n\n

Ordem de pesquisa de chave<\/h3>\n\n\n\n

Nosso objetivo era usar um mecanismo de descoberta de chave que fornece:\u00b7  Confirma\u00e7\u00e3o positiva da propriedade da chave \/ resist\u00eancia ao vandalismo\u00b7  Resist\u00eancia \u00e0 censura\u00b7  Descentraliza\u00e7\u00e3o N\u00e3o encontramos uma m\u00eddia que suporte todos os tr\u00eas pontos acima, ent\u00e3o decidimos oferecer suporte a v\u00e1rios mecanismos.<\/strong> Quando um usu\u00e1rio procurando por uma chave p\u00fablica<\/a>, a plataforma Mailfence usa a seguinte ordem de pesquisa de chave:1 – Web Key Directory (WKD): o propriet\u00e1rio do dom\u00ednio atua como uma \u00e2ncora de confian\u00e7a para confirma\u00e7\u00e3o positiva da propriedade da chave (atrav\u00e9s da TOFU modelo). 1 – Web Key Directory (WKD): o propriet\u00e1rio do dom\u00ednio atua como um \u00e2ncora de confian\u00e7a para confirma\u00e7\u00e3o positiva da propriedade da chave (atrav\u00e9s do modelo TOFU). Se uma chave p\u00fablica for encontrada, o processo de pesquisa de chave ser\u00e1 interrompido.2 –   Validating Key Server (VKS): a propriedade do endere\u00e7o de e-mail \u00e9 realizada via double opt-in valida\u00e7\u00e3o. N\u00e3o ser controlado\/gerenciado por um propriet\u00e1rio de dom\u00ednio de chave p\u00fablica oferece um n\u00edvel de resist\u00eancia \u00e0 censura.A valida\u00e7\u00e3o de assinatura e a atualiza\u00e7\u00e3o do status da chave p\u00fablica s\u00e3o sempre feitas usando o VKS (nenhuma ordem de pesquisa est\u00e1 envolvida).Ainda n\u00e3o encontramos um mecanismo adequado que ofere\u00e7a o n\u00edvel desejado de descentraliza\u00e7\u00e3o (um dos valores fundadores do OpenPGP) e continuamos atentos aos esfor\u00e7os em andamento nesse sentido.<\/a><\/p>\n\n\n\n

Outros<\/h2>\n\n\n\n