Confundir intermediários maliciosos com HTTPS e segurança de transporte estrito HTTP

Dada a quantidade de dados pessoais que fluem pela grande série de tubos que é a Internet, a criptografia não é algo que podemos ou devemos ignorar facilmente. Os navegadores modernos oferecem vários mecanismos que podem ser usados para garantir que os dados dos usuários estejam seguros durante o trânsito: cookies seguros e Strict Transport Security são dois dos mais importantes. Elas permitem que você proteja seus usuários de forma simples, atualizando as conexões deles para HTTPS e garantindo que os dados do usuário nunca sejam enviados de forma não criptografada.

Por que isso é importante para você? Considere o seguinte:

Enviar uma página da Web por uma conexão HTTP não criptografada é mais ou menos o mesmo que entregar um envelope não lacrado para a primeira pessoa que você encontra na rua e que parece estar indo na direção dos correios. Se você tiver sorte, ela pode levar o pedido até o fim ou entregá-lo para a próxima pessoa que ela encontrar que estiver indo para o caminho certo. Essa pessoa pode fazer o mesmo, e assim por diante.

A maioria dos estranhos nessa cadeia improvisada é confiável e nunca vai bisbilhotar sua carta aberta ou alterá-la. No entanto, quanto mais vezes a carta mudar de mãos, maior será o número de pessoas com acesso completo à carta que você está enviando. No final, é muito provável que o destinatário da sua carta receba algo pelo correio, mas se esse algo é o mesmo que você entregou em primeiro lugar é uma questão aberta. Talvez você tivesse que lacrar o envelope…

Intermediários

Para o bem ou para o mal, grandes faixas da Internet dependem da confiabilidade de estranhos. Os servidores não estão conectados diretamente entre si, mas transmitem solicitações e respostas de roteador para roteador em um jogo de telefone enorme.

Você pode conferir esses saltos em ação com o traceroute. O caminho do meu computador para o HTML5Rocks é mais ou menos assim:

$ traceroute html5rocks.com
traceroute to html5rocks.com (173.194.71.102), 30 hops max, 60 byte packets
 1  router1-lon.linode.com (212.111.33.229)  0.453 ms
 2  212.111.33.233 (212.111.33.233)  1.067 ms
 3  217.20.44.194 (217.20.44.194)  0.704 ms
 4  google1.lonap.net (193.203.5.136)  0.804 ms
 5  209.85.255.76 (209.85.255.76)  0.925 ms
 6  209.85.253.94 (209.85.253.94)  1.226 ms
 7  209.85.240.28 (209.85.240.28)  48.714 ms
 8  216.239.47.12 (216.239.47.12)  22.575 ms
 9  209.85.241.193 (209.85.241.193)  36.033 ms
10  72.14.233.180 (72.14.233.180)  43.222 ms
11  72.14.233.170 (72.14.233.170)  43.242 ms
12  *
13  lb-in-f102.1e100.net (173.194.71.102)  44.523 ms

13 saltos não é ruim, na verdade. No entanto, se eu estiver enviando solicitações por HTTP, cada um desses roteadores intermediários terá acesso completo às minhas solicitações e às respostas dos servidores. Todos os dados são transferidos como texto simples não criptografado, e qualquer um desses intermediários pode agir como um homem no meio, lendo meus dados ou até mesmo manipulando-os em trânsito.

Pior ainda, esse tipo de interceptação é praticamente indetectável. Uma resposta HTTP modificada de forma maliciosa parece exatamente como uma resposta válida, já que não existe nenhum mecanismo que permita garantir que os dados recebidos sejam _exatamente_ os enviados. Se alguém decidir virar minha Internet de cabeça para baixo para se divertir, não há muito o que eu possa fazer.

Esta é uma linha segura?

Mudar de HTTP de texto simples para uma conexão HTTPS segura oferece a melhor defesa contra intermediários. As conexões HTTPS criptografam todo o canal de ponta a ponta antes que qualquer dado seja enviado, o que torna impossível para as máquinas entre você e o destino ler ou modificar dados em trânsito.

A omnibox do Chrome fornece muitos detalhes sobre o status de uma conexão.
A omnibox do Chrome fornece muitos detalhes sobre o status de uma conexão.

A segurança que o HTTPS oferece está enraizada no conceito de chaves criptográficas públicas e privadas. Uma discussão detalhada dos detalhes está (felizmente) muito além do escopo deste artigo, mas a premissa principal é bastante simples: os dados criptografados com uma determinada chave pública só podem ser descriptografados com a chave privada correspondente. Quando um navegador inicia um handshake HTTPS para criar um canal seguro, o servidor fornece um certificado que fornece ao navegador todas as informações necessárias para verificar a identidade, verificando se o servidor está com a chave privada adequada. Toda a comunicação a partir desse momento é criptografada de modo a provar que as solicitações são enviadas para o servidor autenticado e as respostas são recebidas dele.

Portanto, o HTTPS garante que você está se comunicando com o servidor que você acha que está se comunicando e que ninguém mais está ouvindo ou mexendo nos bits da rede. Esse tipo de criptografia é um pré-requisito absoluto para a segurança na Web. Se o aplicativo não for entregue por HTTPS, ele será vulnerável a ataques. Corrigir. O Ars Technica tem um ótimo guia para conseguir e instalar um certificado (sem custo financeiro) que eu recomendo para conferir detalhes técnicos. A configuração vai variar de provedor para provedor e de servidor para servidor, mas o processo de solicitação de certificado é o mesmo em todos os lugares.

Segurança por padrão

Depois de solicitar e instalar um certificado, garanta que os usuários se beneficiem do seu trabalho árduo: migre os usuários atuais para conexões HTTPS de forma transparente com o redirecionamento HTTP e garanta que os cookies sejam somente enviados por conexões seguras.

Por aqui, por favor

Quando um usuário visitar http://example.com/, redirecione-o para https://example.com/ enviando uma resposta 301 Moved Permanently com um cabeçalho Location adequado:

$ curl -I http://mkw.st/
HTTP/1.1 301 Moved Permanently
Server: nginx/1.3.7
...
Keep-Alive: timeout=20
Location: https://mkw.st/

É possível configurar esse tipo de redirecionamento facilmente em servidores como Apache ou Nginx. Por exemplo, uma configuração do Nginx que redireciona de http://example.com/ para https://example.com/ tem esta aparência:

server {
    listen [YOUR IP ADDRESS HERE]:80;
    server_name example.com www.example.com;
    location "/" {
        rewrite ^(.*) https://www.example.com$1 permanent;
    }
}

Os cookies permitem que os usuários tenham uma experiência de login perfeita no protocolo HTTP sem estado. Os dados armazenados em cookies, incluindo informações sensíveis, como IDs de sessão, são enviados com cada solicitação, permitindo que o servidor identifique para qual usuário ele está respondendo no momento. Depois de garantir que os usuários estão acessando nosso site por HTTPS, também precisamos garantir que os dados sensíveis armazenados em cookies sejam transferidos apenas por uma conexão segura e nunca enviados de forma não criptografada.

A configuração de um cookie geralmente envolve um cabeçalho HTTP parecido com este:

set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT

É possível instruir o navegador a restringir o uso do cookie para proteger as sessões adicionando uma única palavra-chave:

Set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT; secure

Os cookies definidos com a palavra-chave secure nunca serão enviados por HTTP.

Fechando a janela aberta

O redirecionamento transparente para HTTPS significa que, na maior parte do tempo, os usuários que acessam seu site estarão usando uma conexão segura. No entanto, isso deixa uma pequena janela de oportunidade para ataques: a conexão HTTP inicial está aberta, vulnerável a SSL stripping e ataques relacionados. Como um homem do meio tem acesso completo à solicitação HTTP inicial, ele pode atuar como um proxy entre você e o servidor, mantendo você em uma conexão HTTP não segura, independentemente das intenções do servidor.

É possível reduzir o risco dessa classe de ataque pedindo ao navegador para aplicar a Segurança de transporte restrito HTTP (HSTS). O envio do cabeçalho HTTP Strict-Transport-Security instrui o navegador a fazer o redirecionamento HTTP para HTTPS do lado do cliente, sem tocar na rede. Isso também é ótimo para a performance. A melhor solicitação é aquela que você não precisa fazer:

$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000

Os navegadores compatíveis com esse cabeçalho (atualmente Firefox, Chrome e Opera: o caniuse tem detalhes) vão registrar que esse site específico solicitou acesso somente HTTPS, o que significa que, independentemente de como um usuário acessa o site, ele vai ser visitado por HTTPS. Mesmo que ela digite http://example.com/ no navegador, ela vai acabar no HTTPS sem fazer uma conexão HTTP. Melhor ainda, se o navegador detectar um certificado inválido (potencialmente tentando falsificar a identidade do seu servidor), os usuários não poderão continuar por HTTP. Ou tudo ou nada, o que é excelente.

O navegador vai expirar o status HSTS do servidor após max-age segundos (cerca de um mês neste exemplo). Defina um valor razoavelmente alto.

Também é possível garantir que todos os subdomínios de uma origem estejam protegidos adicionando a diretiva includeSubDomains ao cabeçalho:

$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000

Vá em frente, com segurança

O HTTPS é a única maneira de ter certeza de que os dados enviados chegam intactos ao destinatário. Configure conexões seguras para seus sites e aplicativos hoje mesmo. É um processo bastante simples e ajuda a manter os dados dos clientes seguros. Depois de configurar um canal criptografado, redirecione os usuários de forma transparente para essa conexão segura, independentemente de como eles acessam seu site, enviando uma resposta HTTP 301. Em seguida, verifique se todas as informações sensíveis da sessão dos usuários usam apenas essa conexão segura adicionando a palavra-chave secure ao definir cookies. Depois de fazer tudo isso, garanta que os usuários nunca sejam excluídos acidentalmente: proteja-os garantindo que o navegador deles faça a coisa certa enviando um cabeçalho Strict-Transport-Security.

Configurar o HTTPS não é muito trabalhoso e tem grandes benefícios para seu site e os usuários. Vale a pena tentar.

Recursos

  • A StartSSL oferece certificados verificados por domínio sem custo financeiro. Não tem como vencer o sem custo financeiro. É possível e com preço razoável aumentar o nível de verificação.
  • Teste de servidor SSL: depois de configurar o HTTPS para seus servidores, verifique se você fez isso corretamente executando o teste de servidor do SSL Labs. Você vai receber um relatório bem detalhado que mostra se você está realmente pronto para usar.
  • O artigo recente da Ars Technica "Como proteger seu servidor da Web com SSL/TLS" vale a pena ler para saber mais detalhes sobre a configuração de um servidor.
  • Vale a pena ler a especificação de segurança de transporte estrito do HTTP (RFC6797) para conferir todas as informações técnicas sobre o cabeçalho Strict-Transport-Security que você precisa.
  • Depois de saber o que está fazendo, uma possível próxima etapa seria anunciar que o site só pode ser acessado por um conjunto específico de certificados. Há alguns trabalhos em andamento no IETF que permitem fazer isso usando o cabeçalho Public-Key-Pins. Ainda é cedo, mas é interessante e vale a pena acompanhar.