Porta VPN inoltrata: cosa possono vedere i visitatori e il fornitore

Inoltrare una porta dà agli sconosciuti una rotta verso un servizio attraverso l'indirizzo pubblico del fornitore. Questo singolo cambiamento incide insieme sull’esposizione e sulla riconoscibilità, e nessuno dei due pubblica il nome di chi gestisce il servizio. Tenere i due aspetti separati evita gli errori opposti di trattare l'inoltro come anonimato e di trattarlo come identificazione. Tre domande li separano nettamente, e le risposte vengono da prove diverse.

Tre oggetti, tre domande diverse

Tenete l’indirizzo pubblico separato dall’applicazione che risponde dietro di esso, e tenete entrambi separati dalla persona o dall’organizzazione che gestisce la cosa. Ciascuno ha il proprio pubblico e le proprie prove. Mescolarli produce conclusioni che suonano ordinate e sono sbagliate.

Percorreteli in quest’ordine. La prima è una domanda di raggiungibilità, la seconda è una domanda di identità dell’applicazione, e la terza è una domanda di attribuzione che le prime due illuminano solo in parte. Quando qualcuno chiede se l’inoltro di porta è privato, chiedete quale delle tre intende. Le risposte differiscono davvero, e una pagina di policy di solito ne affronta solo una.

Che cosa può collegare un visitatore tra endpoint

Un visitatore si connette all’endpoint e vede ciò che l’applicazione presenta legittimamente: un 'nome host', un nome di certificato, una pagina di accesso, contenuti pubblicati. Questi dettagli identificano il servizio anche quando il suo indirizzo abituale di accesso è nascosto dietro il tunnel. Due endpoint che presentano lo stesso sito nominato danno agli osservatori una base per collegarli. Nulla in questo comportamento è una fuga, perché l’applicazione è stata progettata per essere vista.

La corrispondenza di certificati, reindirizzamenti e contenuto delle pagine tra due endpoint è un segnale forte che appartengono a un solo servizio. Resta un’affermazione sul servizio, non su una persona, finché un altro registro non collega i due.

Le linee guida sulla privacy dell’IETF descrivono come gli identificatori persistenti permettano di correlare le interazioni nel tempo. La correlazione non è attribuzione, perché più persone possono amministrare un solo servizio e un indirizzo può spostarsi tra abbonati non collegati. È questa distinzione che impedisce a un risultato di correlazione di trasformarsi in un’accusa.

Che cosa deve sapere il fornitore dell’inoltro

Per consegnare una connessione in ingresso, il sistema del fornitore deve mantenere la relazione attiva tra il punto d'ingresso pubblico e la destinazione interna. Questo fatto operativo è diverso da ciò che vede un visitatore, e ancora diverso da ciò che il fornitore sceglie di conservare. Tenete separate le due domande quando leggete una pagina di policy, perché una è inevitabile e l’altra è una decisione. Un'affermazione che non viene conservata alcuna cronologia di navigazione non dice nulla sulla cronologia delle mappature.

Se mappature storiche, associazioni di account o registri di connessione persistano è una questione che riguarda la policy e l’implementazione effettive del fornitore. L’inoltro non dimostra che ogni categoria venga registrata. Chiedete specificamente quali campi sopravvivono dopo il ritiro della mappatura, e per quanto tempo.

La raggiungibilità in ingresso è separata anche dall’instradamento in uscita del client, dal DNS e dal comportamento in caso di guasto. Aggiungere una mappatura non descrive come esce il resto del traffico del client.

Quanto dura la mappatura cambia l’esposizione

Una mappatura può persistere per una sessione, per una prenotazione o secondo una policy del fornitore che la modifica. Non vanno presunti né l’assegnazione permanente né la rotazione costante; leggete il comportamento documentato del prodotto e annotate ciò che osservate. Due osservazioni a una settimana di distanza dicono più sulla 'rotazione' di qualsiasi frase di marketing nella pagina del prodotto. Annotate l’intervallo osservato accanto all’endpoint nelle vostre note, perché l’intervallo fa parte dell’esposizione.

La durata cambia quale correlazione è possibile. Un endpoint stabile invita a un monitoraggio di lungo periodo di un solo servizio, mentre uno rotante rende ogni osservazione più difficile da unire alla precedente. Nessuna delle due proprietà è una garanzia sui registri del fornitore, e nessuna sostituisce la decisione su ciò che il servizio stesso pubblica.

Pubblicate deliberatamente, poi chiudete entrambe le porte

Confermate che il fornitore consenta il protocollo che vi serve, che l’ascoltatore di destinazione sia quello che intendevate, e che i controlli dell’host e dell’applicazione limitino ancora l’accesso. Prima di pubblicare, guardate che cosa il servizio presenterà a uno sconosciuto. Questi due comandi mostrano il certificato e le intestazioni che un visitatore riceve.

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

Pubblicare qualcosa non giustifica esporne le pagine di amministrazione né abbandonare l’accesso dell’applicazione, e la traduzione non fornisce TLS a un servizio che non l’ha mai avuto. Mantenete il protocollo cifrato e i suoi controlli di identità del server al loro posto, indipendentemente da come arriva il traffico. Poi controllate le intestazioni di risposta, perché un banner o una pagina di debug può dire a uno sconosciuto più di quanto il servizio intenda. Ciò che i due comandi restituiscono è la stessa vista che ottiene un osservatore.

Ritirare il servizio significa due chiusure, non una: ritirate la mappatura tramite il suo proprietario, poi trattate l’ascoltatore e il diritto come voci separate. Un endpoint salvato nei segnalibri che smette di rispondere non revoca una credenziale e non recupera informazioni già consegnate.