Porta VPN encaminhada: o que visitantes e o provedor podem ver

Encaminhar uma porta dá a desconhecidos uma rota até um serviço através do endereço público do provedor. Essa única mudança afeta a exposição e a reconhecibilidade ao mesmo tempo, e nenhuma delas publica o nome de quem opera o serviço. Manter as duas separadas evita os erros opostos de tratar o 'encaminhamento' como anonimato e de tratá-lo como identificação. Três perguntas separam-nas com clareza, e as respostas vêm de evidências diferentes.

Três objetos, três perguntas diferentes

Mantenha o endereço público separado da aplicação que responde por trás dele, e mantenha ambos separados da pessoa ou organização que opera a coisa. Cada um tem o seu público e as suas provas. Misturá-los produz conclusões que soam arrumadas e estão erradas.

Percorra-as nessa ordem. A primeira é uma pergunta de alcançabilidade, a segunda é uma pergunta de identidade da aplicação e a terceira é uma pergunta de atribuição que as duas primeiras só esclarecem em parte. Quando alguém perguntar se o encaminhamento de portas é privado, pergunte qual das três quer dizer. As respostas diferem de verdade, e uma página de políticas normalmente aborda apenas uma delas.

O que um visitante pode ligar entre extremos

Um visitante liga-se ao extremo e vê o que a aplicação apresenta legitimamente: 'um nome de anfitrião', um nome de certificado, uma página de início de sessão, conteúdo publicado. Esses detalhes identificam o serviço mesmo quando o seu endereço habitual de acesso está oculto atrás do túnel. Dois extremos que apresentam o mesmo sítio nomeado dão aos observadores uma base para os ligar. Nada nesse comportamento é uma fuga, porque a aplicação foi concebida para ser vista.

A coincidência de certificados, redirecionamentos e conteúdo de páginas entre dois extremos é um sinal forte de que pertencem ao mesmo serviço. Continua a ser uma afirmação sobre o serviço, não sobre uma pessoa, até que outro registo ligue os dois.

As orientações de privacidade do IETF descrevem como os identificadores persistentes permitem correlacionar interações ao longo do tempo. A correlação não é atribuição, pois várias pessoas podem administrar um único serviço e um endereço pode passar entre subscritores não relacionados. É essa distinção que impede que uma descoberta de correlação se transforme numa acusação.

O que o provedor de encaminhamento precisa de saber

Para entregar uma ligação de entrada, o sistema do provedor tem de manter a relação ativa entre o ponto de entrada público e o destino interno. Esse facto operacional é diferente do que um visitante vê, e diferente ainda do que o provedor decide conservar. Mantenha as duas perguntas separadas quando lê uma página de políticas, porque uma é inevitável e a outra é uma decisão. Uma afirmação de que não se guarda histórico de navegação não diz nada sobre o histórico de mapeamentos.

Se os mapeamentos históricos, as associações de conta ou os registos de ligação persistem é uma questão para a política e a implementação reais do provedor. O encaminhamento não prova que cada categoria seja registada. Pergunte especificamente que campos sobrevivem após a retirada do mapeamento, e durante quanto tempo.

A alcançabilidade de entrada também está separada do encaminhamento de saída do cliente, do DNS e do comportamento em caso de falha. Acrescentar um mapeamento não descreve como sai o resto do tráfego do cliente.

Quanto tempo o mapeamento dura muda a exposição

Um mapeamento pode persistir durante uma sessão, durante uma reserva ou segundo uma política do provedor que o altere. Nem a atribuição permanente nem a rotação constante devem ser presumidas; leia o comportamento documentado do produto e registe o que observa. Duas observações separadas por uma semana dizem mais sobre a 'rotação' do que qualquer frase de marketing na página do produto. Anote o intervalo observado junto ao extremo nas suas notas, porque o intervalo faz parte da exposição.

A duração muda que correlação é possível. Um extremo estável convida ao acompanhamento a longo prazo de um serviço, enquanto um rotativo torna cada observação mais difícil de ligar à anterior. Nenhuma das duas propriedades é uma garantia sobre os registos do provedor, e nenhuma substitui a decisão sobre o que o próprio serviço publica.

Publique deliberadamente e depois feche as duas portas

Confirme que o provedor permite o protocolo de que precisa, que o ouvinte de destino é o que pretendia e que os controlos do anfitrião e da aplicação ainda limitam o acesso. Antes de publicar, veja o que o serviço apresentará a um desconhecido. Estes dois comandos mostram o certificado e os cabeçalhos que um visitante recebe.

openssl s_client -connect pub.example.net:443 -brief < /dev/null
curl -sSI https://pub.example.net/

Publicar algo não justifica expor as suas páginas de administração nem abandonar o início de sessão da aplicação, e a tradução não fornece TLS a um serviço que nunca o teve. Mantenha o protocolo cifrado e as suas verificações de identidade do servidor no lugar, independentemente de como o tráfego chega. Depois verifique os cabeçalhos de resposta, porque um 'banner' ou uma página de depuração pode dizer a um desconhecido mais do que o serviço pretende. O que os dois comandos devolvem é a mesma vista que um observador obtém.

Retirar o serviço significa dois fechos, não um: retire o mapeamento através do seu proprietário e depois trate o ouvinte e o direito como itens separados. Um extremo guardado nos marcadores que deixa de responder não revoga uma credencial nem recupera informação já entregue.