O que uma especificação de protocolo VPN prova e o que não prova

Um documento de protocolo é um contrato entre implementações, e lê-lo com atenção diz-lhe o que dois pares conformes vão trocar e que propriedades os criadores pretendiam garantir. Não lhe diz que binário está a correr no servidor a que se liga, como esse servidor foi configurado ou o que acontece depois ao registo da sua conta. São três tipos diferentes de prova, e tratar a especificação como se fosse os três é a forma como um nome de protocolo começa a fazer um trabalho que não pode fazer. Manter os três separados é todo o exercício.

O documento é o começo de um argumento, não a sua conclusão.

O que o documento especifica realmente

Para WireGuard, a descrição do protocolo define um aperto de mão Noise IK, um conjunto fixo de primitivas, disposições de mensagem e o enquadramento de transporte que depois transporta pacotes. Para IKEv2, o artefacto comparável é o RFC 7296, que especifica trocas, cargas úteis e a negociação de propostas. Em ambos os casos o âmbito é preciso: as mensagens, a máquina de estados e os pressupostos sob os quais os objetivos de segurança se aplicam.

Os modos opcionais complicam a leitura. Uma propriedade que se verifica para um aperto de mão pode não se aplicar a uma implementação com outra disposição de autenticação ou uma configuração de reserva.

Onde as garantias terminam

Uma análise formal responde a uma pergunta sobre um modelo. O trabalho de verificação do WireGuard usa um modelo simbólico no provador Tamarin, que pode mostrar que o desenho resiste a certos ataques dadas as suas premissas; não mostra que uma implementação distribuída no espaço de utilizador não tenha qualquer falha de segurança de memória. É nessa lacuna entre modelo e máquina que vivem os incidentes reais. Ler uma prova como certificado de implementação é um erro de categoria.

O sigilo perseverante ilustra a mesma fronteira. A propriedade depende de as chaves serem destruídas como o protocolo pretende, e isso é uma propriedade da implementação e do seu ambiente, não do formato da mensagem. Um desenho que prescreve o apagamento não o pode impor numa plataforma que envia memória para o disco.

As dependências em camadas alargam ainda mais a lacuna: a biblioteca TLS por trás de um túnel baseado em TLS, a interface do núcleo usada por um túnel no espaço de utilizador e o gerador de números aleatórios estão todos fora do texto do protocolo.

Siga os bytes até à compilação

Passe do documento aos artefactos identificando versões e comparando-as depois com o que realmente serve tráfego. Um produto que nomeia um protocolo pode acrescentar componentes de aprovisionamento, telemetria e gestão que a especificação nunca descreve.

openvpn --version | head -3
wg --version
dpkg -l | grep -E 'openvpn|wireguard|libssl'
ss -lunp | grep -E '1194|51820'
sha256sum ./wireguard-tools_1.0.20210914_amd64.deb

Compilações reproduzíveis e somas de verificação publicadas tornam possível ligar uma árvore de código fonte a um binário distribuído. Sem essa ligação, a fonte publicada só prova que a inspeção é possível, não que o ficheiro em execução lhe corresponda.

A configuração pertence ao mesmo passo. As suítes de cifra, os pares permitidos e as definições de encaminhamento são escolhas de implementação, e uma compilação conforme configurada com descuido continua a produzir um túnel fraco.

Mantenha as práticas operacionais separadas

Os registos de conta, os dados de pagamento e os pedidos de suporte são decisões do operador que nenhum texto de protocolo restringe. Um relatório de auditoria cobre componentes nomeados dentro de um âmbito declarado, e uma política de privacidade descreve intenções e práticas; nenhum substitui o outro, e nenhum é uma afirmação criptográfica.

A conclusão precisa é cumulativa: a especificação explica o desenho, a compilação e a configuração explicam o túnel, e as práticas documentadas do operador explicam tudo o que o túnel nunca vê. Diga qual destes verificou, e a afirmação mantém-se verdadeira.