Antes de começarmos a falar sobre Perfect Forward Secrecy (PFS), vamos entender um pouco sobre o contexto de como chegamos até aqui. Nos momentos iniciais do uso da Internet, em nossas comunicações entre cliente e servidor não existia muita preocupação em manter a segurança. Isso não era um foco na época.
Então, por volta de 1994, uma empresa chamada Netscape Communications Corporation (originalmente Mosaic Communications Corporation), que à época desenvolvia um navegador chamado Netscape – e se você, assim como eu, lembra dele, quero te dizer que estamos velhos – começou a introduzir a ideia de comunicação segura. Para isso, usavam um protocolo que iria garantir a integridade e a privacidade dos dados.
Você também pode ouvir a versão em áudio deste conteúdo:
E foi assim que deu-se início a este processo de segurança nas comunicações que foi reforçado em 1999 pela Engineering Task Force (IETF), o tornando como um padrão de comunicação. Isto evoluiu e chegamos às versões mais novas do atual protocolo chamado SSL.
O SSL é um excelente protocolo, seguro em suas últimas versões mas, ainda ligado fortemente ao uso de chaves criptográficas que devem ser trocadas e usadas para a criptografia de todo o canal de comunicação.
O que acontece é que todo conteúdo é criptografado usando esta chave trocada entre o cliente e ou servidor. No entanto, por mais que seja seguro, todo conteúdo usa apenas uma única chave.
Pensando nisso, podemos imaginar un cenário onde um atacante pode capturar todo tráfego trocado durante o processo de comunicação. Mesmo que não possa ter acesso ao conteúdo – por estar criptografado – ele pode armazenar este conteúdo e depois buscar comprometer ou conseguir a chave usada para a criptografia. Este é um cenário real é já foi demonstrado como possível.
Enfim, chegamos ao pensamento relevante para o entendimento do FPS.
FPS – Perfect Forward Secrecy – o que é
Sem entrarmos muito nos detalhes de construção do protocolo, o FPS é um modelo criptográfico onde são produzidas chaves de criptografia temporárias entre o cliente e o servidor.
Então, o que há de diferente com o modelo utilizado pelo TLS?
Imaginando uma comunicação normal entre um cliente e um servidor usando TLS, teremos a utilização de uma chave secreta assim como no FPS. Mas ao realizarmos uma nova comunicação, ou de de outro usuário cliente com o mesmo servidor, utilizaremos a mesma chave secreta para estabelecer a nova conexão – e é esta a diferença.
Sendo assim, para cada uma das sessões criadas entre o cliente e o servidor há também a criação de uma chave única e individual, garantindo a exclusividade de chave para aquela sessão.
Isso quer dizer que se houver o vazamento do conteúdo daquela sessão, sem a chave nada pode ser acessado, nada mudou com relação ao modelo já conhecido. No entanto, como temos uma chave por sessão iniciada, a chave apenas pode ser usada para conteúdos gerados.
Desta forma, com foco em proteção dos dados da camada de transporte, o FPS tem se tornado padrão de segurança. Como tal, ele deve ser observado pelos desenvolvedores para a implementação de serviços de mensagens e ou mesmo para sistemas que tenham como foco a garantia da privacidade do usuário.
Desta forma, sistemas de trocas de mensagens que usam como modelo o FPS podem alterar as chaves criptográficas com a mesma frequência com que trocam mensagens. Para reforçar isso, recentemente a Internet Engineering Task Force publicou um documento revisando o padrão de TLS e agora colocando como obrigatório o uso de FPS para todas as conexões.
Como utilizar o FPS – Perfect Forward Secrecy
Utilizar o FPS é relativamente simples, pois funciona em sites que usam SSL ou TLS.
Portanto, como sabemos, o SSL e o TLS são protocolos criptográficos que permitem que exista uma comunicação conexão segura.
Sabendo disso, para que ocorra a conexão segura entre o servidor e a máquina do usuário, ambos devem concordar sobre o tipo de criptografia que será utilizado.
Para garantir que o FPS seja usado, você simplesmente precisa configurar seus servidores para oferecer estes dois protocolos de comunicação:
- Ephemeral Diffie-Hellman (DHE)
- Ephemeral Elliptic Curve Diffie-Hellman (ECDHE)
No entanto, a troca de chaves devem ser configuradas para que sejam utilizadas apenas uma única vez. Dentro do processo, isso se denomina troca de chaves efêmeras. Após acontecer a transação, a criptografia relacionada à troca é excluída do servidor. E é esse processo de exclusão que garante que a cada nova conexão uma nova chave será criada.
Habilitando FPS em seu servidores NGINX e Apache
Se você verificar as configurações de segurança de um site e visualizar que há o uso do “ECDHE” ou “DHE”, este servidor já está usando o FPS.
A maioria dos servidores modernos já terá isso configurado.
Mesmo assim, se você ainda não tem o FPS habilitado, podemos mostrar nos exemplos a seguir que é bastante simples.
Nginx
First, locate your SSL protocol configuration (assuming /etc/nginx is the base directory for your Nginx installation):
- Primeiro você deve localizar seu arquivo de configuração do SSL(/etc/nginx)
grep -r ssl_protocol /etc/nginx
- Assim que localizar, basta adicionar estas linhas no arquivo.
ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
ssl_prefer_server_ciphers on;
- Defina quais cifras serão utilizadas, e para isso você tem algumas opções. O que você deve ficar atento é qual o nível de compatibilidade com browser mais antigos você quer mas, pode escolher a lista abaixo, por exemplo:
ssl_ciphers ‘EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH’;
- Agora basta reiniciar o serviço.
sudo service nginx restart
Apache
- Localize o arquivo de configuração:
grep -i -r “SSLEngine” /etc/apache
- Adicione estas linhas no arquivo::
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
- Defina as cifras a serem utilizadas:
ssl_ciphers ‘EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH’;
- Reinicie o serviço:
apachectl -k restart
É importante observar que mesmo sendo fácil configurar o FPS, também é fácil configurar isso de forma incorreta. Isso que pode significar que, mesmo estando habilitado, pode não ser o tipo de segurança que está sendo usando.
E um dos erros mais comuns é simplesmente ativar o suporte para DHE ou ECDHE e não habilitar esses métodos como prioritário no servidor. Isso quer dizer que se outro método de segurança for priorizado pelo servidor, esse será o usado.
O que pode ser uma boa idéia é desativar todos os outros tipos de segurança caso você tenha decidido usar o FPS. Isso pode evitar o Freak Attack.
Da mesma forma é importante que você desabilite IDs de sessão de longa duração ou mesmo os tíquetes de sessão. Isso porque nestes dois parâmetros há informações relacionadas às sessões, mesmo depois do término da sessão no lado do usuário.
Onde se usa o Perfect Forward Secrecy
O FPS é e foi fortemente adotado pelos provedores de informações desde seu início, e é conhecido como um recurso de segurança crucial.
Um exemplo é o signal, protocolo de mensagens para criptografia de ponta a ponta que hoje é utilizado no WhatsApp, Google Allo e no Facebook Messenger tornou mais popular o FPS.
Conhecido como o sistema de “double ratchet”, o protocolo do signal cria uma nova chave para cada mensagem. Mais recentemente, surgiu uma nova funcionalidade que é um recurso que permite que as mensagens possam se autodestruir.
Um dos primeiros casos de uso foi em 2011 quando o Google começou a entregar o Gmail, GSuite – ainda chamado de Google Docs – e para seus usuários que utilizam seu mecanismo de pesquisa uma comunicação usando o FPS.
Além disso, o Twitter também passou a oferecer o FPS para todos os usuários desde 2013. Já a Apple começou em 2016 a adotar um novo protocolo de forma obrigatório para todos os aplicativos iOS que exigem o uso de App Transport Security.
SAIBA MAIS SOBRE NOSSOS SERVIÇOS
Um processo evolutivo
Com este artigo tivemos como objetivo apresentar uma nova possibilidade de segurança em comunicações, e acreditamos que conseguimos iniciar um pouco a curiosidade para aqueles que ainda não conheciam o FPS, esperamos realmente que tenha sido apenas o começo.
O que vale é entender que a segurança é um processo evolutivo e sempre temos coisas novas e que podem ser usadas ainda mais nos sistemas e aplicações que criamos.
Nos vemos no próximo artigo.
LEIA TAMBÉM: O IAM e a segurança do CI/CD
