Um VPN pago pode autorizar sessões sem a sua conta?
Tokens não vinculáveis podem separar a verificação de elegibilidade da própria sessão. O que importa é o desenho de emissão e resgate, não o rótulo no login.
Pagar por um túnel não precisa de significar apresentar a identidade de cobrança em cada ligação. Um desenho pode verificar a elegibilidade uma vez, entregar ao cliente tokens criptográficos e deixar o gateway aceitar um token mais tarde sem ver a conta por trás dele. Se isso esconde alguma coisa depende das escolhas de emissão e resgate, portanto trate-o como um exercício de especificação com quatro secções em vez de uma funcionalidade que se liga.
Separe o passo da compra do passo da sessão
A arquitetura Privacy Pass do RFC 9576 dá o vocabulário: um cliente, um atestador, um emissor e uma origem. O cliente prova uma propriedade ao emissor e recebe tokens; mais tarde apresenta um à origem, que decide se o serve. Aplicada a um VPN, a propriedade atestada pode ser uma única unidade de acesso.
A cobrança continua a ver o que o seu próprio processo precisa, e ninguém afirma o contrário. O objetivo mais estreito é que o resgate posterior não possa ser ligado à compra que produziu o token. É uma propriedade concreta e testável, e é a que vale a pena escrever.
Uma cadeia bearer com aspecto aleatório não a proporciona. Se o emissor guarda o valor ao lado de um registo de cliente e o gateway pode pedir esse mapeamento, as duas interações ficam ligadas por base de dados em vez de por criptografia. A construção tem de tornar o emissor incapaz de responder a essa pergunta, e a implementação tem de impedir que o emissor e o gateway juntem as suas visões.
Decida o que autoriza um token
«Um token compra acesso» não responde a quase nada em termos operacionais. A unidade é uma ligação, uma franquia de tempo ou um volume? Um cliente que perdeu a resposta pode retomar a mesma concessão? O que acontece quando um dispositivo se volta a ligar durante uma mudança de rede? Essas respostas determinam se o desenho é utilizável, e cada uma tem uma consequência de privacidade.
| 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 |
Escolha uma deliberadamente e escreva o comportamento em caso de falha ao lado. Um cliente que tenta de novo com uma nova titularidade após um tempo limite consome outra unidade, o que é ao mesmo tempo uma surpresa na fatura e um sinal de privacidade.
Escreva a política de reutilização e revogação
A revogação é onde os desenhos anónimos costumam quebrar a sua própria promessa. Cancelar uma subscrição e invalidar tokens já emitidos são operações diferentes, e um gateway que faz discretamente uma consulta de conta para decidir deixa de ser anónimo nesse ponto.
Escolha uma validade, um limite de emissão e uma história de revogação que encaixem. Depois verifique os próprios registos do gateway à procura de campos que reintroduzam a ligação que removeu.
sudo grep -rIl --include='*.log' -e 'Bearer ' -e 'account_id' /var/log/vpn/
Essa pesquisa lista ficheiros de log que contêm campos de token ou de conta, que é o primeiro sítio onde um desenho cuidadoso perde na prática. Um registo de sessão que guarda o valor do token ao lado de um identificador de conta derrota toda a construção, e normalmente chega através de uma alteração de depuração a que ninguém voltou.
Defina também o que o gateway guarda depois de a sessão terminar. Duração, bytes e endpoint são úteis para operações, e cada um deles é uma peça do puzzle que um observador gostaria de ter. Mantenha o período de retenção curto e a lista de campos curta, e reveja ambos quando uma alteração de depuração acrescenta uma coluna. Ninguém repara num novo campo de log antes de ele lá estar há um ano.
Enuncie a afirmação e depois as observações que permanecem
Escreva a afirmação de privacidade numa frase com os seus pressupostos: que parte tem de ser incapaz de ligar que contextos, e o que acontece se o emissor e o gateway compararem notas. Um desenho que sobrevive a essa frase é auditável; um descrito apenas como «zero conhecimento» não é.
Depois liste o que continua visível de qualquer maneira. Endereços de origem, horas de ligação, tamanhos de pacote e o simples facto de uma compra ter acontecido pouco antes de aparecer a única ligação nova estão todos fora da criptografia. Um único cliente que compra uma unidade e se liga uma vez é vinculável só pelo momento, e nenhum desenho de token muda isso.
O resultado honesto é uma ligação mais estreita entre conta e utilização, não uma sessão invisível. Continua a valer a pena construir, desde que a documentação o diga e os registos operacionais correspondam à afirmação.