Czy płatny VPN może autoryzować sesje bez Twojego konta?
Tokeny, których nie da się powiązać, pozwalają oddzielić sprawdzenie uprawnień od samej sesji. Liczy się projekt wydawania i realizacji tokenów, a nie etykieta na ekranie logowania.
Płacenie za tunel nie musi oznaczać przedstawiania tożsamości płatniczej przy każdym połączeniu. Projekt może raz sprawdzić uprawnienia, przekazać klientowi kryptograficzne tokeny i pozwolić bramie zaakceptować token później, bez widzenia konta, które za nim stoi. To, czy naprawdę coś to ukrywa, zależy od decyzji o wydawaniu i realizacji, więc potraktuj to jako ćwiczenie ze specyfikacji złożone z czterech części, a nie funkcję, którą się włącza.
Oddziel etap zakupu od etapu sesji
Architektura Privacy Pass z RFC 9576 daje słownik pojęć: klient, poświadczający, wystawca i źródło. Klient dowodzi pewnej właściwości wobec wystawcy i otrzymuje tokeny; później przedstawia jeden z nich źródłu, które decyduje, czy go obsłużyć. Zastosowane do VPN, poświadczaną właściwością może być pojedyncza jednostka dostępu.
Rozliczenia nadal widzą to, czego potrzebuje ich własny proces, i nikt nie twierdzi inaczej. Węższym celem jest to, że późniejszej realizacji nie da się powiązać z zakupem, który wytworzył token. To konkretna, testowalna właściwość i warto ją zapisać.
Losowo wyglądający ciąg bearer tego nie zapewnia. Jeśli wystawca przechowuje wartość obok rekordu klienta, a brama może zapytać o to odwzorowanie, obie interakcje łączy baza danych, a nie kryptografia. Konstrukcja musi uniemożliwić wystawcy odpowiedź na to pytanie, a wdrożenie musi nie dopuścić, by wystawca i brama połączyli swoje widoki.
Zdecyduj, do czego uprawnia jeden token
„Jeden token kupuje dostęp” nie mówi operacyjnie prawie nic. Czy jednostką jest jedno połączenie, limit czasu czy wolumen? Czy klient, który zgubił odpowiedź, może wznowić to samo uprawnienie? Co się dzieje, gdy urządzenie łączy się ponownie w trakcie zmiany sieci? Te odpowiedzi decydują o użyteczności projektu, a każda z nich ma skutek dla prywatności.
| Reuse rule | What it buys | What it leaks |
|---|---|---|
| Single use per connection | Strongest unlinkability between sessions | Frequent reissuance, more purchase-to-use timing pairs |
| Bounded time window | Fewer tokens, reconnects work | Activity inside the window is linkable |
| Long-lived grant | Operationally simple | Behaves like an account reference with extra steps |
Wybierz jedną świadomie i zapisz obok sposób postępowania przy błędzie. Klient, który po przekroczeniu czasu ponawia próbę z nowym uprawnieniem, zużywa kolejną jednostkę, co jest jednocześnie niespodzianką na rachunku i sygnałem prywatnościowym.
Zapisz zasady ponownego użycia i unieważniania
Unieważnianie to miejsce, w którym anonimowe projekty zwykle łamią własną obietnicę. Anulowanie subskrypcji i unieważnienie już wydanych tokenów to różne operacje, a brama, która po cichu wykonuje wyszukanie konta, by zdecydować, przestaje być w tym momencie anonimowa.
Wybierz termin ważności, limit wydawania i historię unieważniania, które do siebie pasują. Następnie sprawdź własne rejestry bramy pod kątem pól, które wprowadzają z powrotem usunięte powiązanie.
sudo grep -rIl --include='*.log' -e 'Bearer ' -e 'account_id' /var/log/vpn/
To wyszukiwanie wylicza pliki dziennika zawierające pola tokenów lub kont, co jest pierwszym miejscem, w którym staranny projekt przecieka w praktyce. Rekord sesji przechowujący wartość tokenu obok identyfikatora konta niweczy całą konstrukcję, a zwykle trafia tam przez zmianę debugowania, do której nikt nie wrócił.
Zdefiniuj też, co brama zachowuje po zakończeniu sesji. Czas trwania, bajty i punkt końcowy są przydatne operacyjnie, a każdy z nich to element układanki, który obserwator chciałby mieć. Utrzymuj krótki okres przechowywania i krótką listę pól, a potem przejrzyj oba, gdy zmiana debugowania doda kolumnę. Nikt nie zauważa nowego pola dziennika, dopóki nie stoi tam od roku.
Sformułuj twierdzenie, a potem obserwacje, które pozostają
Zapisz twierdzenie o prywatności w jednym zdaniu wraz z założeniami: która strona musi nie móc powiązać których kontekstów i co się dzieje, jeśli wystawca i brama porównają notatki. Projekt, który przetrwa to zdanie, da się ocenić; taki, który opisuje się tylko jako „zero wiedzy”, nie.
Następnie wypisz, co pozostaje widoczne niezależnie od wszystkiego. Adresy źródłowe, czasy połączeń, rozmiary pakietów i prosty fakt, że zakup nastąpił krótko przed pojawieniem się jedynego nowego połączenia, są poza kryptografią. Pojedynczy klient kupujący jedną jednostkę i łączący się raz da się powiązać samym wyczuciem czasu i żaden projekt tokenu tego nie zmieni.
Uczciwym wynikiem jest węższe powiązanie konta z użytkowaniem, a nie niewidzialna sesja. Nadal warto to budować, o ile dokumentacja tak mówi, a rejestry operacyjne zgadzają się z twierdzeniem.