Este es un experimento mental sobre la interacción entre Tor, OpenID y uno (o más) nodos comprometidos en la ruta segura. Estoy centrado en cómo usar la tecnología de manera que agregue valor a una solución de nube segura. No tengo ningún interés en utilizar esta tecnología para propósitos nefarios.
Caso de uso
Supongamos que tengo un servidor multiusuario donde cada cliente determina la visibilidad de su dominio. Por ejemplo: x.myhost.com
puede elegir ser "público" y xyz.myhost.com
es privado y solo se puede acceder mediante una dirección oculta .onion
.
Según tengo entendido, hay dos formas de que un servidor interactúe con Tor:
- No haga nada, use SSL y confíe en que el último nodo de salida no se haya comprometido
- "Enganche" a la red Tor usando un servicio oculto y una dirección .onion
Amenazas
Por lo que entiendo, la sesión es vulnerable a un nodo .EXIT comprometido. Algunos hacks que he leído incluyen:
- divulgación de datos protegidos por SSL
- Pérdida de anonimato si el usuario utiliza muchos servicios en la misma red Tor, lo que permite la correlación
Pregunta
Ahora que el mundo se está moviendo hacia la autenticación basada en notificaciones, SAML y OpenID, ¿cómo debería usarse Tor con estas tecnologías, considerando que los nodos .exit podrían estar comprometidos? Dado que existen hacks de correlación, ¿debería usarse OpenID / SAML? Algunas preguntas que afectan a la arquitectura incluyen
- ¿OpenID público es menos seguro que aquellos con autenticación basada en formularios?
- ¿El uso de OpenID / SAML permite la correlación de sesión? ¿Algunos proveedores de OpenID son mejores que otros?
- ¿Debe el servidor OpenID / SAML tener una dirección .onion? ¿Eso ayudará a prevenir los ataques de correlación?
- ¿Hay ventajas de usar un servidor público de OpenID (Google / Yahoo) para uno privado (Microsoft ADFSv2)