Hvad en VPN-protokolspecifikation beviser, og hvad den ikke beviser

Et protokoldokument er en kontrakt mellem implementeringer, og en omhyggelig læsning fortæller, hvad to konforme parter udveksler, og hvilke egenskaber designerne havde til hensigt skulle holde. Det fortæller ikke, hvilken binærfil der kører på serveren, du forbinder til, hvordan den server er konfigureret, eller hvad der bagefter sker med din kontopost. Det er tre forskellige slags bevis, og at behandle specifikationen som alle tre er måden, hvorpå et protokolnavn begynder at gøre arbejde, det ikke kan. At holde de tre adskilt er hele øvelsen.

Dokumentet er begyndelsen på et argument, ikke dets konklusion.

Hvad dokumentet faktisk specificerer

For WireGuard definerer protokolbeskrivelsen et Noise IK-håndtryk, et fast sæt primitiver, beskedlayout og den transportindramning, der bagefter bærer pakker. For IKEv2 er det sammenlignelige artefakt RFC 7296, som specificerer udvekslinger, nyttelaster og forhandlingen af forslag. I begge tilfælde er omfanget præcist: meddelelserne, tilstandsmaskinen og de antagelser, hvorunder sikkerhedsmålene gælder.

Valgfrie tilstande gør læsningen mere kompliceret. En egenskab, der gælder for ét håndtryk, gælder måske ikke for en udrulning med et andet godkendelsesarrangement eller en reservekonfiguration.

Hvor garantierne stopper

En formel analyse besvarer et spørgsmål om en model. WireGuards verifikationsarbejde bruger en symbolsk model i Tamarin-beviseren, som kan vise, at designet modstår visse angreb givet dets antagelser; det viser ikke, at en udsendt implementering i brugerrummet ikke har en hukommelsessikkerhedsfejl. Det gab mellem model og maskine er, hvor rigtige hændelser lever. At læse et bevis som et implementeringscertifikat er en kategorifejl.

Forward secrecy illustrerer den samme grænse. Egenskaben afhænger af, at nøgler ødelægges, som protokollen har til hensigt, og det er en egenskab ved implementeringen og dens miljø, ikke ved beskedformatet. Et design, der foreskriver sletning, kan ikke håndhæve det på en platform, der skriver hukommelse til disk.

Lagdelte afhængigheder udvider gabet yderligere: TLS-biblioteket bag en TLS-baseret tunnel, kernegrænsefladen, som en tunnel i brugerrummet bruger, og tilfældig talgeneratoren ligger alle uden for protokolteksten.

Følg bytes ind i buildet

Bevæg dig fra dokument til artefakter ved at identificere versioner og derefter sammenligne dem med det, der faktisk betjener trafik. Et produkt, der navngiver en protokol, kan tilføje komponenter til klargøring, telemetri og styring, som specifikationen aldrig beskriver.

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

Reproducerbare builds og offentliggjorte kontrolsummer gør det muligt at forbinde et kildetræ med en distribueret binærfil. Uden det led beviser offentliggjort kildekode kun, at inspektion er mulig, ikke at den kørende fil svarer til den.

Konfiguration hører til samme trin. Ciphersuiter, tilladte parter og routingindstillinger er udrulningsvalg, og et konformt build, der er konfigureret sjusket, giver stadig en svag tunnel.

Hold driftspraksis adskilt

Kontoposter, betalingsdata og supportindberetninger er operatørbeslutninger, som ingen protokoltekst begrænser. En revisionsrapport dækker navngivne komponenter inden for et angivet omfang, og en privatlivspolitik beskriver hensigter og praksis; ingen af dem erstatter den anden, og ingen af dem er en kryptografisk erklæring.

Den præcise konklusion er kumulativ: specifikationen forklarer designet, buildet og konfigurationen forklarer tunnelen, og operatørens dokumenterede praksis forklarer alt, hvad tunnelen aldrig ser. Sig, hvad af dette du har verificeret, og påstanden forbliver sand.