O que a operadora vê dentro de um túnel VPN celular

Uma conexão celular que transporta uma VPN tem duas proteções independentes, e quase toda afirmação confusa sobre privacidade móvel vem de fundi-las. A rede de rádio protege o próprio acesso e a sinalização. O cliente VPN autentica um gateway e protege o tráfego até esse gateway. Nenhuma delas é uma camada da outra, e a operadora não se torna par da VPN só porque encerra a proteção de acesso celular.

Passo 1: desenhe as duas relações

De um lado estão o telefone e a rede móvel: registo, portadores de rádio e qualquer proteção que a norma de acesso especifique. Do outro estão o cliente VPN e um gateway remoto específico, com a sua própria autenticação e as suas próprias chaves.

Pontos finais diferentes, material de chave diferente, modos de falha diferentes. Desenhe-os como duas linhas em vez de uma.

Passo 2: marque onde cada uma termina

Num túnel IPsec em modo túnel, o cliente envolve o pacote interno num novo pacote IP externo e a rede encaminha esse cabeçalho externo. A especificação ESP descreve essa encapsulagem diretamente: a carga útil é protegida, o endereçamento externo é o que o caminho vê.

phone -- cellular access protection -- radio network
phone -- ESP outer packet ------> office gateway -- inner traffic

Nada ao longo do caminho desencripta a carga útil num salto encaminhado. O processamento ocorre no ponto final configurado, e é por isso que as duas fronteiras de proteção não colapsam numa só.

Passo 3: liste o que a operadora ainda pode fazer

Uma operadora de acesso consegue ver destinos externos, temporização e volume. Também pode afetar a entrega através de encaminhamento, filtragem, perda ou ligação cortada. Um túnel lento ou falhado é, portanto, perfeitamente possível sem qualquer desencriptação do seu conteúdo. Picos de latência e reconexões forçadas pertencem à mesma categoria.

Observação e perturbação são capacidades reais. Não são a mesma capacidade que ler a carga útil interna.

Passo 4: mantenha os pressupostos honestos

A conclusão vale para um túnel suportado e corretamente configurado entre pontos finais em que confia. Não sobrevive a um telefone comprometido, credenciais roubadas, um conjunto de cifras obsoleto ou um gateway que seja ele próprio malicioso. Também não torna inofensivo um aviso de certificado inesperado; trate-o como um incidente próprio e não como algo para clicar e ignorar. Cada um desses quebra um pressuposto e não a criptografia.

Remover a validação de par ou de certificado para fazer desaparecer um aviso altera a relação de proteção em que estava a confiar.

Passo 5: siga os dados para além do gateway

A proteção VPN termina no ponto final configurado. O que o tráfego faz a seguir só é protegido pelo que corre nessa camada, e é por isso que uma sessão HTTPS devidamente validada continua a importar depois do túnel. Texto não cifrado enviado adiante a partir do gateway precisa da sua própria avaliação.

Esta é a parte que as pessoas esquecem quando descrevem um túnel como cobrindo todo o caminho.

Passo 6: delimite os fluxos que estão realmente protegidos

Verifique a política do cliente quanto a aplicações excluídas, túnel dividido e famílias de endereços. Uma aplicação excluída, uma família de endereços não tratada ou uma sessão desligada podem usar um caminho completamente diferente, e um ícone de estado não lhe dirá qual fluxo foi para onde.

Escreva o registo como quatro factos: a rede de acesso, o ponto final VPN autenticado, o ponto final da aplicação e o tráfego realmente coberto. Esse registo mantém-se verdadeiro mesmo quando os ícones mentem.