Serviço Onion versus serviço VPN: modelos de acesso diferentes

As pessoas descrevem um serviço Onion e um serviço acessível apenas por VPN como duas variantes da mesma ideia: esconder a porta e partilhar o endereço secreto. Diferem naquilo a que o endereço está ligado, em quem o pode alcançar e no que tem de acontecer antes de chegar um pedido. Um é um ponto de encontro dentro do Tor, o outro é uma rota dentro de uma rede privada. Tratá-los como intercambiáveis produz desenhos que não são privados nem sustentáveis.

O mito: ambos os desenhos são apenas uma porta escondida

A propriedade partilhada é real mas ténue: nenhum dos desenhos coloca a interface administrativa numa porta pública diretamente acessível. Tudo o resto diverge. Um endereço Onion é derivado da própria chave do serviço, por isso o nome está ligado a uma identidade; um endereço VPN é apenas um endereço dentro de uma rede em que foi admitido. Um esconde o serviço dentro de uma camada sobreposta, o outro admite-o numa topologia privada. Tratar o segundo como sinónimo do primeiro é onde começa a confusão.

Nenhuma das duas propriedades é um controlo de segurança para a própria aplicação. Um local escondido não corrige o software por trás dele, e uma rota privada não acrescenta autenticação à página de início de sessão. Ambos os desenhos continuam a precisar das permissões da própria aplicação, e ambos continuam a precisar de alguém responsável pelas atualizações e pelo restauro.

Para o que aponta realmente um endereço Onion

Um endereço Onion da versão v3 codifica a chave pública do serviço, e é por isso que ninguém pode escolher um endereço para um serviço que não controla. O cliente liga-se através do Tor a um ponto de encontro, e o serviço chega ao mesmo ponto do seu lado; nenhum nó de saída comum transporta essa ligação até ao serviço. O nome é uma identidade, não um registo DNS.

dig +short example.onion
curl --socks5-hostname 127.0.0.1:9050 http://example.onion/
systemctl status tor

Por isso acrescentar uma rota ou uma entrada hosts para um nome onion não serve de nada. A consulta não é o mecanismo; o cliente Tor e os seus circuitos são. Se o serviço se destina a um pequeno grupo de pessoas, a autorização de cliente onion pode exigir uma chave antes de a ligação ser aceite, mas isso continua a não ser o início de sessão da aplicação. Publicar o endereço é também um ato deliberado, pois quem o aprender pode tentar uma ligação a menos que o tenha restringido.

Pare se a única razão do desenho onion for evitar configurar a autenticação. A camada sobreposta não o fornece, e vai construí-la mais tarde de qualquer forma.

O que uma rota VPN concede realmente

Uma VPN admite um dispositivo numa rede e dá-lhe uma rota até um gateway ou uma sub-rede. O serviço atrás desse gateway vê um endereço do conjunto do túnel e aplica a autorização que tiver. A rota não diz nada sobre quem é o utilizador; diz para onde podem ir os pacotes.

ip route get 10.20.30.40
wg show
curl -sv https://files.internal.example/ -o /dev/null

Esse modelo serve um grupo conhecido com dispositivos geridos, porque o gateway pode impor o estado do dispositivo e a rede pode ser auditada. Serve mal visitantes anónimos ou ocasionais, que teriam de ser inscritos primeiro. O início de sessão da própria aplicação continua a decidir o que um utilizador ligado pode ler. Confundir alcance com permissão é como uma VPN acaba por conceder uma sub-rede inteira a todos os que se podem ligar.

Pare se o público é desconhecido ou muda constantemente. Inscrever estranhos numa rede privada para lhes mostrar uma página é um compromisso grande em comparação com publicar um serviço.

Escolher entre os dois, e o que permanece igual

Escolha o modelo onion quando o público é técnico, o serviço não deve ter qualquer endereço público e pode aceitar os requisitos do cliente Tor. Escolha o modelo VPN quando o público é um grupo definido cujos dispositivos gere e cujo acesso quer registar ao nível da rede. Nenhuma escolha elimina a necessidade de autenticação da aplicação, de correções ou de um caminho de recuperação. Nenhuma é automaticamente mais privada no sentido que importa aos seus utilizadores.

Em ambos os desenhos, anote quem pode alcançar o serviço, como é identificado e o que acontece quando uma credencial se perde. A resposta para um serviço onion inclui as suas chaves de autorização de cliente e o próprio endereço; a resposta para uma VPN inclui a conta, o dispositivo e a política do gateway. São inventários diferentes, e só um deles será óbvio para o próximo administrador.

A comparação termina onde começa a aplicação. Um endereço escondido e uma rota privada são escolhas de transporte, e a aplicação ainda tem de decidir o que é permitido a um pedido. Mantenha essas decisões em documentos separados e nenhum dos desenhos absorverá silenciosamente o trabalho do outro.