Tre salti, un solo host: contare le vere dipendenze per la privacy

Il secondo salto si è alzato in orario e il tuo diagramma mostra ancora tre fornitori separati. Poi arrivano le fatture e due di esse citano la stessa società di hosting, lo stesso registrar possiede i tre domini e ogni account si recupera su una sola casella di posta che possiedi tu. Nulla nella configurazione del tunnel è rotto. Il progetto semplicemente non ha mai contato le dipendenze che stanno sotto i salti, e un conteggio dei salti descrive il percorso che prende il traffico, non il numero di parti che potrebbero agire su di esso.

Il sintomo compare nella fatturazione, non nei log

Non lo troverai in un log del tunnel, perché il tunnel fa esattamente ciò che hai configurato. Le prove vivono nei registri pubblici e nelle impostazioni degli account: nomi di organizzazione whois che coincidono tra gli endpoint, server dei nomi identici, un indirizzo del registrante condiviso, un metodo di pagamento, un pannello di controllo. Ognuno di questi è un indizio che due livelli che dovrebbero fallire in modo indipendente possono fallire insieme.

Nessuno di questi indizi dimostra che una singola parte possa leggere il tuo traffico. Ciò che riducono è il numero di decisioni indipendenti che devono andare storte prima che due livelli di protezione siano compromessi dallo stesso evento.

Confronta i registri che puoi davvero vedere e annota cosa hai confrontato. Cerca l’organizzazione su ogni indirizzo di endpoint, elenca i server dei nomi di ogni dominio e apri le impostazioni di recupero di ogni account della catena. Dove due valori coincidono, nota se la coincidenza riguarda la proprietà, le operazioni o solo il front-end di un rivenditore. Sono risultati diversi, e trattarli come uno solo è il modo in cui una revisione delle dipendenze diventa congettura.

Disegna il percorso logico, poi la mappa delle dipendenze

Servono due diagrammi, e la maggior parte delle persone disegna solo il primo. Il percorso logico mostra dove termina ogni livello di protezione e cosa quell’endpoint può osservare. La mappa delle dipendenze mostra chi gestisce e amministra ciascuno di questi endpoint, che è un insieme di nomi del tutto separato.

Valuta ogni riga invece di compilarla. Noto significa che hai visto un registro che lo afferma, dedotto significa che un’osservazione lo sostiene senza risolverlo, e sconosciuto significa che non è stato trovato nulla. Un marchio di hosting condiviso è una deduzione su un’infrastruttura condivisa, non un’affermazione su un database di clienti condiviso. Non promuovere in silenzio una deduzione a fatto noto solo perché è comoda per la conclusione che ti aspettavi.

Una riga vuota è di per sé un risultato. Ti dice quale fatto cambierebbe la decisione se lo apprendessi, ed è più utile di un altro paragrafo su cosa potrebbe fare un avversario sofisticato.

Un numero di AS risponde solo a una domanda di routing

Un sistema autonomo è un concetto di amministrazione del routing, un insieme di indirizzi presentato alle altre reti come un’unica vista di routing coerente. Numeri di AS diversi quindi non dicono nulla di definitivo sulla proprietà aziendale, su personale separato o su un controllo legale indipendente. L’errore opposto è altrettanto comune: due endpoint nello stesso AS non sono automaticamente il caso di una parte che identifica un utente specifico.

Se vuoi i numeri, risolvili invece di presumerli. L’indirizzo sotto è un segnaposto, e il flag chiede allo strumento di etichettare ogni salto con l’AS che lo annuncia.

mtr --aslookup --report --report-cycles 5 203.0.113.9

Tratta quell’output come una misura del routing, non della proprietà o del percorso completo del traffico. La rete di accesso da cui parti e le dipendenze di transito tra gli endpoint sono domande separate a cui gli indirizzi degli endpoint non possono rispondere. Quando una rotta o una scelta di relay non è osservabile da dove sei, etichettala come sconosciuta invece di importare un’affermazione generale su come una certa rete seleziona i percorsi oggi. Non osservato non è lo stesso che inosservabile, ma non è nemmeno una prova.

Nomina l’osservazione prima di nominare il rischio

Tre risultati si confondono nella maggior parte delle revisioni delle dipendenze, e separarli è la parte più lunga del lavoro. La visibilità passiva del traffico cifrato è un risultato. L’accesso amministrativo condiviso è un altro, perché implica un’azione e non una vista. Il collegamento degli account è un terzo, perché connette identità senza concedere alcun accesso tecnico.

Le linee guida sulla privacy in RFC 6973 offrono una forma praticabile per questo: elenca cosa apprende ogni entità, poi chiedi come potrebbe essere combinato con informazioni detenute altrove. Due punti su un percorso che osservano schemi di traffico simili possono motivare una preoccupazione di correlazione, ma non ti danno una probabilità misurata che qualcuno sia stato identificato. Scrivi la preoccupazione, poi scrivi l’osservazione che la confermerebbe.

Torna a una catena di due servizi tunnel e di un proxy affittato. Se le credenziali amministrative del proxy condividono un account di recupero con un server tunnel, un singolo compromesso amministrativo può attraversare entrambi i confini. Se l’unica sovrapposizione è che una società di hosting gestisce entrambe le macchine, la revisione deve indicare quali poteri ha quella società e quali informazioni restano protette. Gli stessi tre salti, un risultato diverso.

Il registro non è un certificato di anonimato e non lo sarà mai. Il suo valore è più stretto e più pratico: mostra dove l’indipendenza è stabilita, dove è assunta e quale singola riga sconosciuta sposterebbe la decisione. Scegli quella riga la prossima volta, e lascia in pace il resto del diagramma finché non ne avrai una risposta.