Autenticación fuerte sobre enlaces inseguros

Si su capa de encapsulación es insegura, puede adaptarse creando una capa segura dentro de ella si tiene una ID de clave pública conocida para el host remoto.

Dado que la IP es insegura, ejecutamos SSL dentro de ella. Debido a que sus sesiones SSL terminan a la fuerza en un host no deseado, lo que las hace inseguras, ejecute otra capa segura en ellas, como SSL. SSL sobre SSL, SSH sobre SSL, o cualquier otra combinación de tunelización debería proporcionar una conexión confiable siempre que verifique la clave de host.

  

todo el tráfico en la red entre el cliente y el servidor se está interceptando y viendo

... implica que también se puede modificar; por lo tanto, no hay sesión, no hay javascript.

  

a lo largo de las líneas de una aplicación web

Entonces, la única forma en que se me ocurre implementar esto es a través de OTP, y deberías deshabilitar el lado del cliente de javascript para evitar falsificaciones de solicitudes de MITB. Pero como no puede confiar en la integridad de la sesión, deberá agregar una nueva contraseña a cada solicitud HTTP para poder autenticarla. Pero si está hablando de una aplicación HTML5 instalada de manera segura, entonces esa es una historia diferente: puede implementar su propio encapsulado de tráfico AJAX utilizando encriptación simétrica + PSK o uno de los crecientes javascript asymmetric libs .

  

Dado que estos están siendo MITM'd activamente

¿Entonces, intentas pasar por alto la política de seguridad local?

Así es como lo hacemos: enlace . Básicamente, el token de software valida que el certificado SSL objetivo que obtiene el usuario es el mismo que el almacenado en el servidor OTP. Si no es válido, entonces no se muestra la OTP. Los tokens usan claves asimétricas para hablar con el servidor, no SSL. Déjame saber si quieres más información.

PSK podría, en ciertas circunstancias, ser una solución. Encripta todos los datos con el PSK. Solo los hosts permitidos podrán comunicarse.