Port VPN reenviat: què poden veure els visitants i el proveïdor

Reenviar un port dona a desconeguts una ruta cap a un servei a través de l'adreça pública del proveïdor. Aquest sol canvi afecta alhora l'exposició i la reconeixibilitat, i cap de les dues publica el nom de qui gestiona el servei. Mantenir-les separades evita els errors oposats de tractar el reenviament com a anonimat i de tractar-lo com a identificació. Tres preguntes les separen netament, i les respostes vénen de proves diferents.

Tres objectes, tres preguntes diferents

Manteniu l’adreça pública separada de l’aplicació que respon al darrere, i manteniu totes dues separades de la persona o l’organització que gestiona la cosa. Cadascuna té el seu públic i les seves proves. Barrejar-les produeix conclusions que sonen ordenades i són errònies.

Recorreu-les en aquest ordre. La primera és una pregunta de connectivitat, la segona és una pregunta d’identitat de l’aplicació, i la tercera és una pregunta d’atribució que les dues primeres només informen en part. Quan algú pregunta si el reenviament de ports és privat, pregunteu a quin dels tres es refereix. Les respostes difereixen de debò, i una pàgina de polítiques normalment només n’aborda una.

Què pot enllaçar un visitant entre punts finals

Un visitant es connecta al punt final i veu el que l'aplicació presenta legítimament: un nom d’amfitrió, un nom de certificat, una pàgina d’inici de sessió, contingut publicat. Aquests detalls identifiquen el servei fins i tot quan la seva adreça habitual d'accés queda amagada darrere el túnel. Dos punts finals que presenten el mateix lloc anomenat donen als observadors una base per enllaçar-los. Res en aquest comportament no és una fuita, perquè l’aplicació es va dissenyar per ser vista.

Fer coincidir certificats, redireccions i contingut de pàgines entre dos punts finals és un senyal fort que pertanyen a un sol servei. Segueix sent una afirmació sobre el servei, no sobre una persona, fins que algun altre registre enllaci els dos.

Les directrius de privacitat de l’IETF descriuen com els identificadors persistents permeten correlacionar interaccions al llarg del temps. La correlació no és atribució, perquè diverses persones poden administrar un sol servei i una adreça pot moure’s entre subscriptors no relacionats. Aquesta distinció és el que impedeix que una troballa de correlació es converteixi en una acusació.

Què ha de saber el proveïdor de reenviament

Per lliurar una connexió entrant, el sistema del proveïdor ha de mantenir la relació activa entre el punt d’entrada públic i la destinació interna. Aquest fet operatiu és diferent del que veu un visitant, i diferent també del que el proveïdor decideix conservar. Manteniu les dues preguntes separades quan llegiu una pàgina de polítiques, perquè una és inevitable i l’altra és una decisió. Una afirmació que no es guarda cap historial de navegació no diu res sobre l'historial d’assignacions.

Si les assignacions històriques, les associacions de compte o els registres de connexió persisteixen és una qüestió per a la política i la implementació reals del proveïdor. El reenviament no demostra que es registri cada categoria. Pregunteu específicament quins camps sobreviuen després que es retiri l’assignació, i durant quant de temps.

La connectivitat entrant també és independent de l’encaminament sortint del client, del DNS i del comportament davant d’errors. Afegir una assignació no descriu com surt la resta del trànsit del client.

Quant dura l’assignació canvia l’exposició

Una assignació pot persistir durant una sessió, durant una reserva o segons una política del proveïdor que la canviï. No s’ha de pressuposar ni l’assignació permanent ni la rotació constant; llegiu el comportament documentat del producte i anoteu el que observeu. Dues observacions separades per una setmana diuen més sobre la 'rotació' que qualsevol frase de màrqueting de la pàgina del producte. Poseu l'interval observat al costat del punt final a les vostres notes, perquè l’interval forma part de l’exposició.

La durada canvia quina correlació és possible. Un punt final estable convida a un seguiment a llarg termini d’un sol servei, mentre que un de rotatori fa que cada observació sigui més difícil d’unir amb l’anterior. Cap de les dues propietats no és una garantia sobre els registres del proveïdor, i cap no substitueix la decisió sobre què publica el servei mateix.

Publiqueu deliberadament i després tanqueu les dues portes

Confirmeu que el proveïdor permet el protocol que necessiteu, que l’oient de destinació és el que volíeu, i que els controls de l’amfitrió i de l’aplicació encara limiten l’accés. Abans de publicar, mireu què presentarà el servei a un desconegut. Aquestes dues ordres mostren el certificat i les capçaleres que rep un visitant.

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

Publicar una cosa no justifica exposar-ne les pàgines d’administració ni deixar caure l’inici de sessió de l’aplicació, i la traducció no aporta TLS a un servei que mai no l’ha tingut. Manteniu el protocol xifrat i les comprovacions d’identitat del servidor al seu lloc, sigui com sigui que arribi el trànsit. Després reviseu les capçaleres de resposta, perquè un bàner o una pàgina de depuració pot dir a un desconegut més del que el servei pretén. El que tornen les dues ordres és la mateixa vista que obté un observador.

Retirar el servei vol dir dos tancaments, no un: retireu l’assignació a través del seu propietari i després tracteu l’oient i el dret com a elements separats. Un punt final desat als marcadors que deixa de respondre no revoca cap credencial ni recupera informació ja lliurada.