Uma VPN protege contra o KRACK? O que o patch corrige
Uma VPN esconde o tráfego da rede local, mas não repara o handshake do WPA2. Aqui está o que o patch de 2017 mudou e o que cada camada cobre.
Se você compra uma VPN porque uma manchete disse que o KRACK quebra a criptografia do Wi-Fi, está consertando a camada errada. Aquela divulgação de 2017 descrevia uma família de ataques de reinstalação de chave contra o handshake de quatro vias do WPA2, e a correção chegou como atualizações do sistema operacional, patches de drivers sem fio e firmware de roteador. Um túnel pode esconder o seu tráfego da rede local, mas não pode reparar um handshake que termina abaixo dele. Então a primeira pergunta não é qual VPN comprar; é qual dos seus dispositivos ainda executa uma pilha sem fio sem patch.
A mesma distinção responde à preocupação com o orçamento. Quem não pode pagar uma assinatura nunca foi excluído do remédio real, porque o remédio era uma atualização gratuita. O que custa dinheiro é substituir hardware que já não recebe nenhuma.
O que o ataque realmente manipulou
O WPA2 deriva uma nova chave de par no momento da associação por meio de um handshake de quatro vias. O ponto de acesso envia um nonce, o cliente responde com o seu, os dois lados calculam a chave transitória de par, e o ponto de acesso confirma com uma mensagem que o cliente acusa. Um ataque de reinstalação de chave interfere nessa sequência em vez de adivinhar a senha, forçando um cliente a instalar uma chave que já instalou. Cada reinstalação pode zerar o nonce de transmissão e o contador de repetição de recepção ligados a essa chave.
Quando esses contadores andam para trás, parte do tráfego que deveria ter sido rejeitado volta a ser aceitável. Dependendo da variante e da implementação, um atacante ao alcance do rádio podia reproduzir quadros, decifrá-los ou injetá-los. O handshake de chave de grupo e o de transição rápida tinham variantes próprias, e por isso o aviso listava vários nomes de ataque em vez de um.
Android 6.0 e posteriores foi o pior caso. As suas versões de wpa_supplicant podiam ser forçadas a instalar uma chave de todos os zeros, o que tornava a decifração muito mais fácil do que em plataformas onde a reinstalação apenas zerava contadores. Esse detalhe separou uma fraqueza teórica de uma prática na plataforma de telefone mais comum da época.
A correção vive na pilha sem fio
A correção original disse aos supplicants e aos pontos de acesso para ignorarem uma mensagem de handshake retransmitida uma vez que a chave já estivesse instalada. As compilações corrigidas de wpa_supplicant e hostapd a traziam, e as distribuições a retroportaram para ramos antigos, então a string impressa por wpa_supplicant -v é um ponto de partida e não um veredicto. Leia o aviso de segurança da distribuição e confirme o patch específico, não apenas o número da versão. Uma compilação que declara uma versão antiga pode estar corrigida, e uma que declara uma nova pode ainda não ter um backport do fabricante.
As duas pontas do enlace precisam de atenção. Um roteador reparado não corrige o notebook que se associa a ele, e um notebook reparado não corrige o roteador. Os fabricantes publicavam avisos por produto, e as correções de roteador costumavam ficar atrás das atualizações de telefone porque cada modelo precisa da sua própria compilação de firmware. Se a última versão de um dispositivo é anterior ao aviso, trate-o como não corrigido até o fabricante dizer o contrário.
Para o equipamento que você não pode atualizar, as opções são estreitas e pouco glamourosas. Aposente-o, mantenha-o longe de redes que carreguem tráfego sensível, ou confine-o a um segmento onde os seus únicos pares sejam igualmente descartáveis. Nenhuma dessas opções envolve uma assinatura, e nenhuma melhora escolhendo outro provedor de túnel.
O que um túnel cobre
Uma VPN move a fronteira. O seu dispositivo cifra cada pacote e o envia a um servidor VPN, que o decifra e o encaminha. Quem manipula o enlace Wi-Fi vê os pacotes externos do túnel, não a carga útil lá dentro, então um ataque de reinstalação que expõe quadros da camada de enlace não expõe automaticamente o conteúdo da conexão tunelada. Essa proteção vale mesmo enquanto a pilha sem fio por baixo continua vulnerável, e é exatamente por isso que os dois controles se confundem.
O qualificador é «tunelado». O tunelamento dividido, uma lista de exceções ou uma exceção de portal cativo enviam parte do tráfego para fora do túnel, e esse tráfego não ganha nada com ele. O mesmo vale para o tráfego de outros dispositivos na mesma rede que nunca instalaram o cliente. Um túnel é uma decisão por dispositivo e por rota, não uma propriedade da sala, e uma VPN ao nível do roteador só cobre o que realmente passa pelo roteador.
O que o túnel não pode fazer é reparar o driver, parar uma enxurrada de desautenticação ou impedir que um atacante interfira no canal. Também não pode proteger uma conexão que nunca entra nele. São problemas de disponibilidade e de camada de enlace, e ficam com a pilha sem fio por mais forte que seja o conjunto de cifras do túnel.
HTTPS e o túnel protegem saltos diferentes
Um único carregamento de página pode envolver três proteções separadas: o enlace Wi-Fi, o túnel até o servidor VPN e a sessão TLS até o site. Cada uma é negociada de forma independente. TLS com um certificado válido e uma versão de protocolo moderna dá a você criptografia autenticada entre navegador e site mesmo quando o primeiro salto é hostil, porque é a verificação do certificado que impede um impostor de substituir a própria chave.
Essa verificação tem pontos fracos nas bordas. Um redirecionamento de HTTPS para HTTP, uma página que carrega scripts por HTTP simples ou um usuário que clica através de um aviso de certificado movem tráfego para fora da sessão protegida. HSTS e as páginas intermediárias do navegador existem porque esses erros são comuns, não porque o TLS seja frágil.
Manter HTTPS e um túnel não faz a implementação sem fio deixar de ser vulnerável. Os quadros continuam a ser decifrados por um driver defeituoso; a diferença é o que o atacante encontra lá dentro e se esse conteúdo já estava protegido por outra coisa.
Ordem de reparação para uma rede mista
Comece pelo ponto de acesso, porque é o dispositivo que você controla e do qual cada cliente depende. Depois percorra os sistemas operacionais dos clientes, do mais antigo ao mais novo, já que as plataformas que deixaram de receber atualizações são as que nunca serão corrigidas. Só quando esse inventário estiver pronto é que uma decisão sobre a VPN faz sentido, e é uma decisão sobre exposição, não sobre reparação. Fazer isso na ordem inversa, primeiro o túnel e depois o firmware, deixa o defeito real no lugar enquanto durar a assinatura.
Anote o que você verificou, incluindo a versão do firmware e a data. «Atualizado» não é um estado que alguém possa auditar depois.
Três verificações cobrem a maior parte do trabalho, e vão nesta ordem. Não pule a terceira só porque as duas primeiras voltaram limpas.
- Firmware do roteador: compare a versão instalada com a página de avisos do fabricante, não com o botão de atualização.
- SO do cliente: confirme o nível de patches que inclui a correção sem fio para cada telefone, notebook e tablet.
- Restos: liste os dispositivos sem caminho de patch e decida aposentar, isolar ou aceitar.
Se a lista de restos for longa, uma rede de convidados com isolamento de clientes ganha tempo enquanto o hardware é substituído. Depois teste um cliente conhecido em cada banda, anote o resultado e verifique de novo após a próxima versão de firmware. O inventário de hardware é o que torna o próximo aviso rápido; o túnel é o que cobre a lacuna nesse meio-tempo.