Aspecto Técnico

Até mesmo a versão mais recente de protocolo torna-se inútil se usada incorretamente. A questão reside em eventuais problemas de desconexão da VPN, levando ao direcionamento do tráfego por uma rede pública. Isso pode ocorrer quando uma empresa se conecta com a VPN por meio de uma rede pública ou celular. O pior é a empresa não ser notificada do ocorrido e a conexão VPN não ser restabelecida automaticamente.

No Windows 7 ou superior, a Microsoft introduziu uma funcionalidade chamada VPN Reconnect. Ela monitora o status da conexão VPN. Caso seja interrompida, o tráfego é bloqueado, os programas em execução são parados, e o mecanismo tenta reestabelecer a VPN. Alguns dos fornecedores oferecem função similar. A segunda falha é o protocolo IPv6. Embora esse protocolo ainda seja incomum, a maioria dos sistemas operacionais o possuem como padrão - porém as VPNs utilizam em maioria o IPv4.

O que pode ocorrer é que quando o IPv6 é suportado em uma rede pública e a empresa tenta se conectar com um recurso que usa a mesma versão do protocolo, o tráfego será direcionado para uma rede pública IPv6 por definição. A medida mais simples para lidar com o problema seria desabilitar completamente o suporte ao IPv6 em nível de sistema.

Pesquisas conduzidas em 2015 apresentaram os problemas para fornecedores de VPN, com intuito de estimulá-los a procurar soluções para seus clientes. A pesquisa também faz referência a um terceiro problema: vazamentos de DNS. Em um cenário ideal, ao se conectar a uma VPN, todas as solicitações de DNS não devem deixar a rede VPN, tendo de ser processada por servidores de DNS correspondentes. Caso contrário, servidores de confiança como o Google Public DNS e o OPenDNS devem ser configurados na instalação da rede.

A resposta incorreta desses servidores abre espaço para que criminosos coloquem seus planos em prática. O vazamento de DNS tem como dano colateral o comprometimento da privacidade: um autor externo pode descobrir o endereço do servidor de DNS, o que o leva ao nome ISP e a partir daí uma estimativa da localização do usuário.

A situação é ainda pior para empresas que utilizam o Windows: Isso porque o Windows 7 testava todos os servidores de DNS conhecidos um por um até obter uma resposta, o Windows 8/8.1 torna tudo mais rápido ao enviar solicitações simultâneas para todos os servidores DNS de conexões conhecidas. Se o servidor com maior prioridade não responder em um minuto, o retorno de outro servidor seria usado. Porém, no caso das VPNs a resposta de uma rede pode demorar mais do que isso.  A boa notícia é que essa função pode ser desativada manualmente; a ruim é que para isso seriam necessárias manipulações no mínimo tediosas no Registro.

No Windows 10, a situação é pior. Ele envia solicitações de DNS para todos os caminhos possíveis e usa o que retornar mais rápido.

Existem também diversas vulnerabilidades de servidor em WebRTC. Essa tecnologia, ao ser ativada no navegador, foi inicialmente projetada para agir como um link direto entre dois nós de rede e usada primariamente para chamadas de áudio e vídeo. Vazamentos nesse caso possuem uma alta probabilidade de ocorrência já que chamadas WebRTC tentam entrar em contato com todas as conexões de rede disponíveis simultaneamente, usando a primeira que responder.

Aspectos legais

O principal problema com VPN diz respeito às diferenças nas legislações entre países: uma empresa que utiliza o VPN poderia estar fisicamente em um país que não encara a tecnologia com bons olhos, mas o servidor de VPN está localizado em outro. Por outro lado, o tráfego pode ser transmitido por países terceiros. Mesmo que você não viole qualquer lei, seus dados podem ser analisados ainda em trânsito. É desconcertante saber que o tráfego dito seguro pode ser decodificado até mesmo anos depois. O uso de VPN pode provocar a atenção desnecessária das autoridades (e se estiverem escondendo algo com o auxílio da rede VPN?). Da mesma forma que pode não existir um único problema legal associado ao uso de VPN, o uso da tecnologia é limitado por condições técnicas.

No fim, todos os problemas legais tendem a ter origem a partir do uso de métodos poderosos de criptografia associados à VPN.  Qualquer país gostaria de proteger suas próprias informações e de quebra colocar a mão nos dados alheios, sendo esse o motivo pelo qual a criptografia é altamente regulada.

Nos EUA, um dos maiores países no setor de TI, a situação é no mínimo curiosa. Novos padrões de criptografia devem ser aprovados pelo Instituto Nacional de Normas e Tecnologia (NIST). Contudo, esses padrões variam em força: a criptografia é mais resiliente para produtos domésticos e fraca para exportados. Empresas parceiras precisam respeitar certas regulamentações.

Não precisamos relembrar onde os principais sistemas operacionais e componentes de criptografia são produzidos. O resultado desses fatores é que tecnologias de rede padronizadas podem se tornar vulneráveis de fábrica.

Prova disso foi o caso ocorrido em 2013 em que a NIST foi acusada de ter permitido que a NSA usasse uma versão vulnerável de um gerador de números pseudoaleatório como base do novo padrão de criptografia.  Em teoria, isso diminuiria o esforço necessário para se desencriptar informações “protegidas”.

As suspeitas começaram a ser levantadas alguns meses após a publicação do novo padrão. Contudo, a agência reguladora era acusada de liberar descrições rebuscadas para recomendações e padrões. Os rascunhos eram inconsistentes ao ponto do entendimento se tornar um desafio mesmo para profissionais experientes do ramo. Não apenas as questões de resiliência e segurança importam, aspectos práticos da implementação também são fundamentais.

Fonte

kaspersky Lab