Co dowodzi specyfikacja protokołu VPN, a czego nie

Dokument protokołu to umowa między implementacjami, a uważne czytanie mówi, co wymienią dwie zgodne strony i jakie właściwości projektanci zamierzali zapewnić. Nie mówi, który plik binarny działa na serwerze, z którym się łączysz, jak ten serwer skonfigurowano ani co później dzieje się z zapisem twojego konta. To trzy różne rodzaje dowodów, a traktowanie specyfikacji jako wszystkich trzech jest sposobem, w jaki nazwa protokołu zaczyna wykonywać pracę, której wykonać nie może. Rozdzielenie tych trzech to całe ćwiczenie.

Dokument jest początkiem argumentu, a nie jego wnioskiem.

Co dokument faktycznie określa

W przypadku WireGuard opis protokołu definiuje uścisk dłoni Noise IK, stały zestaw prymitywów, układy komunikatów i ramkowanie transportowe, które następnie przenosi pakiety. W przypadku IKEv2 porównywalnym artefaktem jest RFC 7296, który określa wymiany, ładunki i negocjowanie propozycji. W obu przypadkach zakres jest precyzyjny: komunikaty, maszyna stanów i założenia, przy których cele bezpieczeństwa obowiązują.

Tryby opcjonalne komplikują lekturę. Właściwość, która obowiązuje dla jednego uścisku dłoni, może nie mieć zastosowania do wdrożenia z innym układem uwierzytelniania lub konfiguracją zapasową.

Gdzie kończą się gwarancje

Analiza formalna odpowiada na pytanie o model. Prace weryfikacyjne WireGuard wykorzystują model symboliczny w dowodziku Tamarin, który może pokazać, że projekt opiera się pewnym atakom przy swoich założeniach; nie pokazuje, że dostarczona implementacja w przestrzeni użytkownika nie ma błędu bezpieczeństwa pamięci. To w tej luce między modelem a maszyną żyją rzeczywiste incydenty. Czytanie dowodu jako certyfikatu implementacji jest błędem kategorii.

Poufność forward secrecy ilustruje tę samą granicę. Właściwość zależy od tego, czy klucze są niszczone tak, jak zamierza protokół, a to właściwość implementacji i jej środowiska, a nie formatu komunikatu. Projekt, który nakazuje wymazywanie, nie może go wymusić na platformie zrzucającej pamięć na dysk.

Zależności warstwowe jeszcze powiększają lukę: biblioteka TLS za tunelem opartym na TLS, interfejs jądra używany przez tunel w przestrzeni użytkownika i generator liczb losowych stoją wszystkie poza tekstem protokołu.

Śledź bajty aż do kompilacji

Przejdź od dokumentu do artefaktów, identyfikując wersje, a następnie porównując je z tym, co rzeczywiście obsługuje ruch. Produkt, który wymienia protokół, może dodawać komponenty aprowizacji, telemetrii i zarządzania, których specyfikacja nigdy nie opisuje.

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

Powtarzalne kompilacje i publikowane sumy kontrolne pozwalają powiązać drzewo źródeł z dystrybuowanym plikiem binarnym. Bez tego powiązania opublikowane źródła dowodzą tylko, że inspekcja jest możliwa, a nie że działający plik jest z nimi zgodny.

Konfiguracja należy do tego samego kroku. Zestawy szyfrów, dozwoleni partnerzy i ustawienia trasowania to wybory wdrożenia, a zgodna kompilacja skonfigurowana niedbale nadal daje słaby tunel.

Trzymaj praktyki operacyjne osobno

Zapisy kont, dane płatności i zgłoszenia do pomocy technicznej to decyzje operatora, których nie ogranicza żaden tekst protokołu. Raport audytu obejmuje nazwane komponenty w zadeklarowanym zakresie, a polityka prywatności opisuje intencje i praktyki; żadne z nich nie zastępuje drugiego i żadne nie jest stwierdzeniem kryptograficznym.

Precyzyjny wniosek jest kumulacyjny: specyfikacja wyjaśnia projekt, kompilacja i konfiguracja wyjaśniają tunel, a udokumentowane praktyki operatora wyjaśniają wszystko, czego tunel nigdy nie widzi. Powiedz, co z tego zweryfikowałeś, a twierdzenie pozostaje prawdziwe.