Un documento de protocolo é un contrato entre implementacións, e lelo con atención dicille que intercambiarán dous pares conformes e que propiedades pretendían garantir os deseñadores. Non lle di que binario se executa no servidor ao que se conecta, como se configurou ese servidor nin que ocorre despois co rexistro da súa conta. Son tres tipos distintos de evidencia, e tratar a especificación como se fose os tres é a forma en que un nome de protocolo comeza a facer un traballo que non pode facer. Manter os tres separados é todo o exercicio.

O documento é o comezo dun argumento, non a súa conclusión.

Que especifica realmente o documento

Para WireGuard, a descrición do protocolo define un aperta de mans Noise IK, un conxunto fixo de primitivas, deseños de mensaxe e o encadramento de transporte que despois transporta paquetes. Para IKEv2 o artefacto comparable é o RFC 7296, que especifica intercambios, cargas útiles e a negociación de propostas. En ambos os casos o alcance é preciso: as mensaxes, a máquina de estados e as suposicións baixo as que se cumpren os obxectivos de seguridade.

Os modos opcionais complican a lectura. Unha propiedade que se cumpre para unha aperta de mans pode non aplicarse a un despregamento con outra disposición de autenticación ou unha configuración de reserva.

Onde se deteñen as garantías

Unha análise formal responde a unha pregunta sobre un modelo. O traballo de verificación de WireGuard usa un modelo simbólico no probador Tamarin, que pode mostrar que o deseño resiste certos ataques baixo as súas suposicións; non mostra que unha implementación de espazo de usuario distribuída non teña ningún fallo de seguridade de memoria. Esa fenda entre modelo e máquina é onde viven os incidentes reais. Ler unha proba como un certificado de implementación é un erro de categoría.

O segredo hacia adiante ilustra a mesma fronteira. A propiedade depende de que as chaves se destrúan como o protocolo pretende, e iso é unha propiedade da implementación e do seu contorno, non do formato da mensaxe. Un deseño que especifica o borrado non pode impoñelo nunha plataforma que envía memoria ao disco.

As dependencias por capas amplían aínda máis a fenda: a biblioteca TLS detrás dun túnel baseado en TLS, a interface do núcleo que usa un túnel de espazo de usuario e o xerador de números aleatorios quedan todos fóra do texto do protocolo.

Segue os bytes ata a compilación

Pase do documento aos artefactos identificando versións e comparándoas despois co que realmente serve tráfico. Un produto que nomea un protocolo pode engadir compoñentes de aprovisionamento, telemetría e xestión que a especificación nunca describe.

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

As compilacións reproducibles e as sumas de comprobación publicadas permiten ligar unha árbore de código fonte cun binario distribuído. Sen esa ligazón, o código publicado só demostra que a inspección é posible, non que o ficheiro en execución se corresponda con el.

A configuración pertence ao mesmo paso. Os conxuntos de cifrado, os pares permitidos e os axustes de encamiñamento son decisións de despregamento, e unha compilación conforme configurada con descoido segue producindo un túnel feble.

Manteña as prácticas operativas aparte

Os rexistros de conta, os datos de pago e as solicitudes de asistencia son decisións do operador que ningún texto de protocolo restrinxe. Un informe de auditoría cobre compoñentes nomeados dentro dun alcance declarado, e unha política de privacidade describe intencións e prácticas; ningunha substitúe a outra, e ningunha é unha afirmación criptográfica.

A conclusión precisa é acumulativa: a especificación explica o deseño, a compilación e a configuración explican o túnel, e as prácticas documentadas do operador explican todo o que o túnel nunca ve. Diga cal destas cousas verificou, e a afirmación segue sendo certa.

Artigos relacionados