Eis uma verdade incômoda: aquele email 'seguro' que você acabou de enviar provavelmente percorreu a internet em uma forma que qualquer atacante suficientemente motivado poderia ler. Não porque a criptografia não exista, mas porque o ecossistema de email tem camadas de criptografia que protegem coisas diferentes — e a maioria das pessoas não entende qual camada protege o quê.
Quando falamos de criptografia de email, na verdade estamos falando de três tecnologias distintas que resolvem três problemas distintos. Confundi-las leva a uma falsa sensação de confiança ou a paranoia desnecessária. Vamos destrinchar isso.
TLS: Criptografando a jornada
Transport Layer Security—TLS—é a criptografia que você obtém por padrão com a maioria dos emails modernos. Quando seu email viaja do seu servidor de correio para o servidor de correio do destinatário, o TLS criptografa essa conexão. Quem interceptar o tráfego verá apenas gibberish.
É a mesma tecnologia que coloca o cadeado na barra de endereços do navegador. É bem compreendida, amplamente implantada e quase invisível. Quando você envia um email pelo Gmail, Outlook ou qualquer serviço de email respeitável, o TLS quase certamente está protegendo a conexão.
Mas o TLS tem uma limitação crítica: ele criptografa apenas os dados em trânsito. Quando seu email chega ao servidor de correio do destinatário, ele é descriptografado e armazenado em texto puro (ou criptografado com as próprias chaves do servidor, às quais o operador do servidor pode ter acesso). Se alguém comprometer o servidor de email, ou se o operador do servidor for obrigado a entregar os dados, o TLS não oferece proteção.
Há outra sutileza: o TLS é negociado entre servidores e nem sempre é garantido. Se o servidor do destinatário não suportar TLS, ou se houver algum problema de configuração, o email pode voltar para transmissão sem criptografia. A maioria dos grandes provedores agora exige TLS, mas isso não é universal. O relatório de transparência do Google mostra que cerca de 10% do Gmail enviado ainda vai para servidores que não suportam criptografia.
Para a maioria dos emails corporativos, o TLS é suficiente. Ele protege contra escuta passiva — alguém “grampeando” o fio entre servidores. Não protege contra servidores comprometidos, exigências legais de dados ou atacantes sofisticados que podem interceptar e modificar o tráfego.
S/MIME: O padrão corporativo
S/MIME—Secure/Multipurpose Internet Mail Extensions—criptografa a própria mensagem de email, não apenas a conexão. O email é criptografado no seu dispositivo antes de sair, e apenas o dispositivo do destinatário pode descriptografá-lo. Os servidores de correio intermediários veem apenas conteúdo criptografado.
S/MIME usa a mesma infraestrutura de certificados que o HTTPS. Você obtém um certificado de uma autoridade certificadora, que contém sua chave pública e verifica sua identidade. Quando alguém quer lhe enviar um email criptografado, usa sua chave pública para criptografá-lo. Só sua chave privada — que nunca sai do seu dispositivo — pode descriptografá-lo.
O mundo corporativo adora S/MIME porque ele se integra à infraestrutura de identidade existente. Se sua empresa já usa certificados para acesso a VPN ou assinatura de código, estender isso para criptografia de email é relativamente direto. O Outlook tem suporte nativo a S/MIME, assim como a maioria dos clientes de email corporativos.
Mas o S/MIME tem fricção. Tanto o remetente quanto o destinatário precisam de certificados. É preciso trocar chaves públicas antes de conseguir se comunicar com segurança. Gerenciar certificados é um transtorno — certificados expiram, são revogados e precisam ser feitos backups. Se você perder sua chave privada, qualquer email criptografado para essa chave estará perdido para sempre.
Há também a questão de em quem você está confiando. Os certificados S/MIME vêm de autoridades certificadoras, o que significa que você está confiando nessas CAs para verificar identidades corretamente e proteger sua infraestrutura. Atacantes de Estados-nação já comprometeram CAs antes. Para a maioria dos modelos de ameaça isso é aceitável, mas não é segurança de ponta a ponta no sentido mais paranoico.
PGP: A escolha cypherpunk
PGP—Pretty Good Privacy—antecipa o S/MIME e adota uma abordagem filosófica diferente. Em vez de depender de autoridades certificadoras, o PGP usa uma 'web of trust' na qual os usuários verificam diretamente as chaves uns dos outros. Não há uma autoridade central decidindo quem é quem.
A criptografia é semelhante ao S/MIME: criptografia de chave pública em que apenas a chave privada do destinatário consegue descriptografar a mensagem. Mas o gerenciamento de chaves é radicalmente diferente. Você gera suas próprias chaves, publica sua chave pública em servidores de chaves ou no seu site, e verifica as chaves de outras pessoas por comunicação direta ou confiando em quem já as verificou.
O PGP é popular entre jornalistas, ativistas e pesquisadores de segurança — pessoas que têm motivos para desconfiar de autoridades centralizadas. Também é notoriamente difícil de usar corretamente. O gerenciamento de chaves é manual e propenso a erros. Historicamente, as ferramentas têm sido hostis ao usuário. Estudos mostram que até usuários técnicos cometem erros que comprometem sua segurança.
O modelo de 'web of trust' soa elegante, mas não escala bem. Na prática, a maioria dos usuários de PGP ou verifica chaves por canais paralelos (encontrando-se pessoalmente, ligando para confirmar impressões digitais) ou simplesmente confia em chaves que encontra online — o que anula grande parte do benefício de segurança.
Há um debate contínuo na comunidade de segurança sobre se o PGP ainda é adequado ao propósito. O protocolo é antigo, as implementações são complexas e os problemas de usabilidade nunca foram resolvidos. Alguns argumentam que alternativas modernas como o Signal (para mensagens) oferecem melhor segurança com menos fricção. Mas, para email especificamente, o PGP continua sendo o padrão para criptografia de ponta a ponta fora do mundo corporativo.
Escolhendo a criptografia certa
Então, qual criptografia você deve usar? Depende do que você quer proteger.
Para emails de negócios em geral, o TLS provavelmente é suficiente. É automático, universal (na maioria), e protege contra as ameaças mais comuns. Garanta que seu provedor de email imponha TLS e considere habilitar MTA-STS para prevenir ataques de downgrade.
Para indústrias regulamentadas ou comunicações internas sensíveis, S/MIME faz sentido. A infraestrutura de certificados se integra ao gerenciamento de identidade corporativo, e os principais clientes de email o suportam nativamente. A sobrecarga de gerenciamento de certificados se justifica pelos benefícios de conformidade e segurança.
Para comunicações realmente sensíveis em que você não confia na infraestrutura — denúncias, jornalismo, ativismo — PGP ou uma plataforma dedicada de mensagens seguras é apropriado. Mas seja realista quanto aos desafios de usabilidade e à segurança operacional necessária para usá-lo de forma eficaz.
Uma nota importante: a criptografia protege o conteúdo, não os metadados. Mesmo com PGP ou S/MIME, observadores podem ver quem envia email para quem, quando e com que frequência. Para alguns modelos de ameaça, esses metadados são tão sensíveis quanto o conteúdo. Se esse for o seu caso, email pode não ser a ferramenta certa independentemente da criptografia.
Frequently asked questions
O Gmail é criptografado?
O Gmail usa TLS para transmissão e criptografa emails armazenados com as chaves do Google. Isso protege contra atacantes externos, mas não contra o próprio Google ou exigências legais. Para criptografia de ponta a ponta em que o Google não pode ler seu email, seria necessário adicionar S/MIME ou PGP.
Posso usar S/MIME e PGP juntos?
Tecnicamente, sim, mas raramente há motivo. Eles resolvem o mesmo problema com modelos de confiança diferentes. Escolha um com base no seu ambiente e modelo de ameaça.
Por que mais pessoas não usam criptografia de email?
Usabilidade. Tanto S/MIME quanto PGP exigem configuração, gerenciamento de chaves e coordenação com os destinatários. Para a maioria das pessoas, a fricção supera o benefício percebido. O TLS oferece segurança 'boa o suficiente' para casos de uso típicos.
E os serviços de email criptografado como o ProtonMail?
Serviços como o ProtonMail criptografam sua caixa de correio com chaves derivadas da sua senha, então nem eles conseguem ler seus emails armazenados. Emails entre usuários do ProtonMail são criptografados de ponta a ponta. Emails para usuários externos podem ser criptografados com uma senha ou recorrem ao TLS.