A proposta do Google, Yahoo e Microsoft para deixar o email mais seguro
Para quem não pode esperar, o ProtonMail pode ser uma alternativa
Temos diversos tipos de redes sociais, serviços de mensagens instantâneas dotados de vários recursos, banda larga suficiente para videoconferência em alta resolução. Nada disso, porém, é capaz de nos fazer abandonar o bom e velho email. Mas há um problema aqui: apesar de sua grande popularidade, o email não é um sistema de comunicação tão seguro quanto poderia ser. A boa notícia é que um grupo de gigantes da internet está disposto a mudar esse cenário.
Para ser exato, esse grupo é formado por engenheiros do Google, Yahoo, Microsoft, LinkedIn, Comcast e 1&1 Mail & Media. Esse time foi formado para criar o SMTP Strict Transport Security (SMTP STS), um mecanismo que faz com que todos os emails transmitidos sejam facilmente criptografados.
É evidente pelo próprio nome que a proposta tem como base o SMTP (Simple Mail Transfer Protocol), o protocolo padrão para envio de emails. O SMTP é antigo: a sua criação remete a 1982. Mas esse protocolo é o tipo de recurso que simplesmente funciona, ou seja, atende às finalidades para as quais foi criado, razão pela qual é usado até hoje com poucas mudanças.
Mas há um deslize nessa história cuja importância só foi notada vários anos mais tarde: quando o SMTP foi criado, a sua associação com algum método de criptografia nem de longe era uma prioridade.
A primeira tentativa: a extensão STARTTLS
O primeiro grande esforço para deixar o protocolo mais seguro surgiu no final da década de 1990. Esse trabalhou levou à criação, em 2002, da STARTTLS, extensão que adiciona ao SMTP a proteção dada pelo protocolo TSL (Transport Layer Security) ou SSL (Secure Socket Layer). Em resumo, o SMTP passou a ter suporte padronizado à criptografia de mensagens.
Até que a STARTTLS foi adotada por um número significativo de provedores de email e afins. Mesmo assim, não dá para dizer que o recurso se tornou um grande sucesso: algumas limitações impediram a sua popularização.
A principal delas é a abordagem “fail open” no lugar de “fail closed”: se determinados erros ocorrerem, a mensagem pode ser enviada sem criptografia em vez de ser barrada. Essa é uma forma de assegurar que a proteção não vai impedir a comunicação. A consequência é que a segurança acaba sendo prejudicada.
Outra limitação relacionada a essa abordagem é a chamada “criptografia oportunista”. Nesse modo de operação, a extensão não valida os certificados digitais dos servidores de email, ou seja, não verifica se as assinaturas dos certificados vêm de um emissor confiável. A premissa aqui é a de que alguma criptografia é melhor do que nenhuma. O problema é que um invasor pode utilizar um certificado de origem duvidosa para descriptografar uma mensagem interceptada.
Google, Yahoo, Microsoft e as demais companhias querem evitar problemas como esse. Para tanto, o SMTP STS está sendo desenvolvido para checar se o domínio do destino suporta o mecanismo (se não, a mensagem poderá ser enviada, mas sem proteção) e verificar se o certificado dos servidores são confiáveis e válidos (ou seja, se já não expiraram, por exemplo).
Assim, os emails podem ser criptografados de modo satisfatório. Se tudo estiver bem, a mensagem chegará à caixa de entrada do destino. Do contrário, o email é barrado e o emissor, como esperado, é notificado para as devidas providências.
Essa é uma proposta interessante, mas que ainda tem um longo caminho pela frente. A ideia foi apresentada oficialmente à Internet Engineering Task Force (IETF) na última sexta-feira e precisa ser analisada ou mesmo ajustada antes de se tornar um padrão. É claro que o fato de o projeto estar sendo tocado por engenheiros de empresas tão importantes pode agilizar o processo.
Uma alternativa chamada ProtonMail
As denúncias de espionagem da NSA que vieram à tona em 2013 despertaram um senso de urgência em relação à segurança dos diversos recursos de comunicação que temos hoje, incluindo o email. Isso significa que, para muita gente, simplesmente esperar o SMTP STS ser amplamente adotado não é uma possibilidade. Para esses casos, uma opção pode ser o ProtonMail.
Esse serviço de email começou a ser desenvolvido em 2014 com a proposta de ser “à prova de NSA”, ou seja, de oferecer criptografia como padrão. Na semana passada, o serviço se tornou público — não é necessário mais convite para criar uma conta.
Muita gente pode pensar que, por oferecer criptografia, o ProtonMail é difícil de usar, mas não é. Se você enviar um email para outra pessoa com conta no ProtonMail, a mensagem é criptografada ali mesmo no navegador e aberta dentro da conta do destinatário. Para tanto, essa pessoa deve utilizar a senha para descriptografar emails que ela definiu ao criar a sua conta (além desta, há a senha de login; é necessário ter atenção).
Se, por outro lado, a mensagem for direcionada a uma conta de um serviço de email convencional (como Gmail ou Outlook.com), você pode clicar no botão com ícone de cadeado no formulário do email e criar uma senha. Ao fazê-lo, o destinatário receberá a mensagem apenas com um link para o conteúdo. Este só poderá ser acessado se o destinatário digitar a senha definida (você deve informá-la por telefone, mensagem instantânea, telepatia etc.).
O ProtonMail é gratuito e oferece 500 MB de espaço. Você pode criar mensagens com prazo de validade, organizá-las com tags, acessá-las via app móvel (para Android e iOS), enfim. Há também uma opção paga que oferece domínio customizado e espaço entre 5 GB e 20 GB por preços que vão de 5 a 20 euros por mês.
Como o ProtonMail não exibe publicidade, os desenvolvedores incentivam a criação de contas pagas porque elas, junto com as doações, são a fonte de receita que garante a manutenção do serviço.
Ah, para quem estranhou, ProtonMail é mesmo um nome inusitado, mas que remete ao “berço” do projeto: o serviço foi idealizado e desenvolvido por Andy Yen, um pesquisador do CERN (o maior laboratório de física de partículas do mundo). Pouco tempo depois, outros pesquisadores da instituição, como Jason Stockman e Wei Sun, se juntaram ao projeto.
Com informações: The Next Web, Ars Technica