Un VPN payant peut-il autoriser des sessions sans ton compte ?
Des jetons non corrélables peuvent séparer la vérification de l'éligibilité de la session elle-même. Ce qui compte, c'est la conception de l'émission et de l'échange, pas l'étiquette sur l'écran de connexion.
Payer pour un tunnel ne veut pas forcément dire présenter l'identité de facturation à chaque connexion. Une conception peut vérifier l'éligibilité une fois, remettre au client des jetons cryptographiques et laisser la passerelle accepter plus tard un jeton sans voir le compte qui se trouve derrière. Savoir si cela cache réellement quelque chose dépend des choix d'émission et d'échange, alors traite-le comme un exercice de spécification en quatre parties, et non comme une fonction que tu actives.
Sépare l'étape d'achat de l'étape de session
L'architecture Privacy Pass de la RFC 9576 fournit le vocabulaire : un client, un attestateur, un émetteur et une origine. Le client prouve une propriété à l'émetteur et reçoit des jetons ; plus tard, il en présente un à l'origine, qui décide de le servir ou non. Appliquée à un VPN, la propriété attestée pourrait être une seule unité d'accès.
La facturation voit toujours ce dont son propre processus a besoin, et personne ne prétend le contraire. L'objectif plus étroit est que l'échange ultérieur ne puisse pas être rattaché à l'achat qui a produit le jeton. C'est une propriété précise et testable, et c'est celle qui mérite d'être écrite.
Une chaîne porteuse d'apparence aléatoire ne la fournit pas. Si l'émetteur stocke la valeur à côté d'un enregistrement client et que la passerelle peut demander cette correspondance, les deux interactions sont liées par une base de données plutôt que par la cryptographie. La construction doit rendre l'émetteur incapable de répondre à cette question, et le déploiement doit empêcher l'émetteur et la passerelle de mettre leurs vues en commun.
Décide ce qu'un jeton autorise
« Un jeton achète l'accès » ne répond presque à rien sur le plan opérationnel. L'unité est-elle une seule connexion, une allocation de temps ou un volume ? Un client qui a perdu sa réponse peut-il reprendre la même autorisation ? Que se passe-t-il lorsqu'un appareil se reconnecte pendant un changement de réseau ? Ces réponses décident si la conception est utilisable, et chacune a une conséquence sur la vie privée.
| 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 |
Choisis-en une délibérément et écris à côté le comportement en cas d'échec. Un client qui réessaie avec un nouveau droit après un délai consomme une autre unité, ce qui est à la fois une surprise de facturation et un signal de vie privée.
Écris la politique de réutilisation et de révocation
La révocation est l'endroit où les conceptions anonymes trahissent généralement leur propre promesse. Annuler un abonnement et invalider des jetons déjà émis sont deux opérations différentes, et une passerelle qui fait discrètement une recherche de compte pour décider n'est plus anonyme à ce moment-là.
Choisis une expiration, une limite d'émission et un récit de révocation qui vont ensemble. Vérifie ensuite les propres enregistrements de la passerelle pour y trouver des champs qui réintroduisent le lien que tu as supprimé.
sudo grep -rIl --include='*.log' -e 'Bearer ' -e 'account_id' /var/log/vpn/
Cette recherche liste les fichiers journaux contenant des champs de jeton ou de compte, et c'est le premier endroit où une conception soignée fuit en pratique. Un enregistrement de session qui stocke la valeur du jeton à côté d'un identifiant de compte ruine toute la construction, et il arrive généralement par une modification de débogage que personne n'a revue.
Définis aussi ce que la passerelle conserve après la fin d'une session. La durée, les octets et le point de terminaison sont utiles à l'exploitation, et chacun d'eux est une pièce du puzzle qu'un observateur aimerait avoir. Garde la durée de conservation courte et la liste de champs courte, puis révise les deux quand une modification de débogage ajoute une colonne. Personne ne remarque un nouveau champ de journal avant qu'il soit là depuis un an.
Énonce l'affirmation, puis les observations qui subsistent
Écris l'affirmation de confidentialité en une phrase avec ses hypothèses : quelle partie doit être incapable de relier quels contextes, et ce qui se passe si l'émetteur et la passerelle comparent leurs notes. Une conception qui survit à cette phrase est révisable ; une conception décrite uniquement comme « connaissance nulle » ne l'est pas.
Liste ensuite ce qui reste visible quoi qu'il arrive. Les adresses source, les heures de connexion, la taille des paquets et le simple fait qu'un achat a eu lieu peu avant l'apparition de l'unique nouvelle connexion échappent tous à la cryptographie. Un seul client qui achète une unité et se connecte une fois est corrélable par le seul moment, et aucune conception de jetons n'y change rien.
Le résultat honnête est un lien plus étroit entre compte et usage, pas une session invisible. Cela vaut tout de même la peine d'être construit, à condition que la documentation le dise et que les enregistrements d'exploitation correspondent à l'affirmation.