VPN TLS versus IPsec: os cinco campos que valem uma revisão

Classificar VPNs TLS contra VPNs IPsec por família de protocolo responde a uma pergunta que ninguém fez, e costuma citar uma construção que ambas as famílias abandonaram anos atrás. O que um revisor pode de fato avaliar é a proteção negociada, a identidade do par, o modelo de cliente e o serviço exposto. Essas quatro coisas são visíveis em uma implantação, e nenhuma delas decorre do rótulo do produto. Peça cinco campos e a conversa fica concreta.

Cinco campos, e o rótulo não é um deles

O primeiro campo é a versão de software suportada, porque uma descrição de protocolo sem versão é um folheto. O segundo é a versão de protocolo negociada, que decide quais construções estão sequer disponíveis. O terceiro é a suíte de proteção, o quarto é o método de autenticação tanto do par quanto do usuário, e o quinto é o escopo de acesso que o produto concede após a admissão.

Um rótulo VPN SSL cobre pelo menos três produtos diferentes: um cliente de rede completo, um proxy de aplicação e um portal legado baseado em navegador. Eles expõem serviços diferentes e falham de formas diferentes, então o rótulo não pode substituir o campo de escopo.

O que a criptografia autenticada realmente muda

O TLS 1.3 exige criptografia autenticada, o que remove do protocolo a construção MAC-then-encrypt mais antiga em vez de deixá-la opcional. O IPsec ESP tem suítes de criptografia autenticada há tanto tempo quanto isso, com o AES-GCM definido em sua própria RFC. Nas duas famílias a garantia vem da suíte negociada e não do nome da família, e é por isso que a lista de campos começa por uma versão. Um revisor que não consegue nomear a suíte não tem nada a avaliar.

É por isso que a comparação histórica engana. Uma implantação fixada em uma versão antiga de TLS com uma suíte CBC e outra executando TLS 1.3 com uma suíte AEAD não têm a mesma postura de segurança, ainda que ambas sejam VPNs TLS. A mesma divisão existe no lado IPsec entre uma suíte ESP moderna e uma combinação legada.

Leia os valores negociados em vez da configuração que você pretendia. Os comandos abaixo mostram no que um endpoint ativo e um túnel ativo realmente concordaram.

openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sas

Se o endpoint não quiser negociar TLS 1.3, isso é um achado e não uma preferência. Se o túnel listar uma suíte que você não esperava, a configuração que importa é a que os pares escolheram, não a do modelo.

A identidade do par é uma pergunta separada

Criptografia sem um par verificado protege o tráfego de observadores e o entrega a quem respondeu à conexão. A autenticação do par pergunta qual identidade é esperada, qual material de confiança a valida e como o cliente se comporta quando a resposta não confere. Uma cadeia de certificados, uma chave fixada e um segredo pré-compartilhado são três respostas diferentes com três custos operacionais diferentes.

Depois faça as mesmas perguntas sobre o usuário ou o dispositivo. Um gateway que autentica a máquina e admite qualquer usuário, ou o contrário, tem uma postura específica que deve ser escrita em vez de presumida. As permissões de recurso aplicadas após a admissão fazem parte do mesmo campo, porque autenticação não é autorização.

Preservar as verificações de nome de host e de certificado importa mais do que a familiaridade da janela de login. Um cliente configurado para ignorar a verificação removeu o único passo que distingue o seu gateway de uma imitação convincente.

O limite que o produto expõe

Um portal sem cliente faz proxy de operações de aplicação selecionadas através do gateway, então o usuário chega a uma interface em vez de a uma rede. Um cliente de túnel completo carrega o que suas rotas e sua política de filtragem selecionam, o que é uma superfície muito maior. Comparar os dois pela força do protocolo perde a diferença no que um atacante pode alcançar por meio deles. Um expõe uma interface de aplicação, o outro expõe uma rede roteada, e os dois exigem revisões diferentes.

Pergunte qual serviço está exposto, quais operações são autorizadas e em que o próprio gateway escuta. Uma interface de administração alcançável a partir do mesmo endereço do portal do usuário é um achado de implantação, e nenhuma escolha de protocolo compensa isso.

O escopo por aplicação estreita ainda mais a superfície, e também muda o comportamento de falha quando o túnel cai. Um projeto que presume alcance de túnel completo quebra de formas que um projeto por aplicativo não quebra, e a carga de suporte acompanha.

Decida o resultado de falha e o ciclo de vida

O que acontece quando a autenticação ou a proteção não está disponível é uma decisão de política que pertence à revisão. Um resultado bloqueado e um fallback direto não anunciado têm consequências diferentes, e a diferença é invisível em uma lista de recursos. Declare o comportamento pretendido ao lado do recurso que ele protege.

Inclua o ciclo de vida de patches e suporte do gateway, seus recursos externos habilitados e o caminho de atualização dos clientes. Uma escolha de protocolo correta não torna seguro um serviço mal implantado, e a maioria dos incidentes vive nessa lacuna e não na suíte.

Escreva os cinco campos, a política de falha e o responsável pelo ciclo de vida em uma página. Essa página é uma revisão; uma comparação de famílias de protocolo é uma opinião.