Questo è un esperimento mentale sull'interazione tra Tor, OpenID e uno (o più) nodi compromessi nel percorso sicuro. Sono concentrato su come utilizzare la tecnologia in un modo che aggiunge valore a una soluzione cloud sicura. Non ho alcun interesse a usare questa tecnologia per scopi nefandi.
Usa caso
Supponiamo di avere un server multi-tenant in cui ciascun cliente determina la visibilità del proprio dominio. Ad esempio: x.myhost.com
può scegliere di essere "pubblico" e xyz.myhost.com
è privato e accessibile solo da un indirizzo .onion
nascosto.
Come ho capito, ci sono due modi in cui un server può interagire con Tor:
- Non fare nulla, usare SSL e fidarsi che l'ultimo nodo di uscita non sia stato compromesso
- "Collegati" alla rete Tor utilizzando un servizio nascosto e un indirizzo .onion
Minacce
Da quanto ho capito, la sessione è vulnerabile a un nodo .EXIT compromesso. Alcuni hack di cui ho letto includono:
- divulgazione di dati protetti da SSL
- Perdita dell'anonimato se l'utente utilizza molti servizi sulla stessa rete Tor, abilitando la correlazione
Domanda
Ora che il mondo si sta muovendo all'autenticazione basata sulle attestazioni, SAML e OpenID, come dovrebbe essere usato Tor con queste tecnologie, considerando che i nodi .exit potrebbero essere compromessi? Dato che esistono degli hacker di correlazione, dovrebbe essere usato OpenID / SAML? Alcune domande che riguardano l'architettura includono
- L'OpenID pubblico è meno sicuro di quelli con l'autenticazione basata su form?
- L'utilizzo di OpenID / SAML abilita la correlazione di sessione? Alcuni provider di OpenID sono migliori di altri?
- Il server OpenID / SAML dovrebbe avere un indirizzo .onion? Questo aiuterà a prevenire gli attacchi di correlazione?
- Ci sono vantaggi nell'usare un server OpenID pubblico (Google / Yahoo) in uno privato (Microsoft ADFSv2)