En este momento, parece que ninguno de los principales navegadores existentes admite TLS-PSK , y ninguno de ellos es compatible con < a href="http://tools.ietf.org/html/rfc5054"> TLS-SRP . En su caso, ambos son aplicables, pero SRP es "más fuerte", ya que tolera mucho mejor un secreto compartido de baja entropía (por ejemplo, una contraseña). Ha habido un esfuerzo inicial para que Chrome tenga en cuenta el SRP; No sé hasta dónde llegó. Dado que todo lo que PSK ofrece puede ser realizado por SRP y posiblemente de una manera mejor y más sólida, es plausible que los navegadores obtengan soporte de SRP antes de que obtengan soporte de PSK. Pero aún no está hecho.
Mientras tanto, puede tener algunas soluciones parciales:
-
Haga que sus usuarios empleen Firefox, con un perfil específico. Un perfil de Firefox incluye, en particular, el conjunto de CA raíz que el navegador utilizará para validar los certificados de servidor; Permítales usar un perfil "vacío" que contenga solo su propia CA.
-
Haz que los usuarios se conecten a través de una VPN. En particular, un túnel SSH: SSH se puede usar como un proxy SOCKS, que el navegador puede usar para cada conexión. El modelo de clave pública de SSH no tiene CA; cada usuario decide qué clave acepta o no.
-
Convierta la aplicación Web en una aplicación genuina y completa instalada en el sistema cliente. Esa aplicación hará el SSL con su servidor y luego podrá elegir el mecanismo de autenticación que desee utilizar.
-
No hagas nada: es el problema del cliente, no del tuyo.
La última "solución alternativa" merece un pensamiento adicional. De hecho, el problema con una posible CA rogue es que estas CA son confiables por el cliente . En un ataque Man-in-the-Middle exitoso, el atacante se hace pasar por un servidor falso. y el cliente le está hablando al atacante, no a usted. Por lo tanto, como primera aproximación, no hay nada que pueda hacer en el servidor que cambie lo que sucede entre el cliente y el atacante. En SSL / TLS, el cliente anuncia todos los conjuntos de cifrado que está dispuesto a usar, y el servidor selecciona uno. Incluso si su servidor quiere usar SRP o PSK, puede apostar a que el servidor del atacante preferirá algún otro conjunto de cifrado.
Por lo tanto, suponiendo que encuentre un navegador compatible con SRP, la seguridad de la conexión contra los atacantes MitM (que podrían sobornar a una CA) no se basa en su uso de SRP en su servidor, sino en el usuario humano : esa bolsa de carne debe esperar SRP (o PSK) y llamar al juego sucio si no lo consigue. MitM será derrotado solo en la medida en que el usuario humano, presentado con un candado verde y una página de inicio de sesión agradable con su logotipo y solicitando su contraseña obtenida mediante SMS, se dirá a sí mismo: "hey, esta es una página web de , no una ventana emergente del navegador ! " y luego se niegan a conectarse. Si puede hacer que sus usuarios reaccionen de manera confiable, entonces probablemente pueda entrenar a un gato para lavar la ropa y limpiar las alfombras al vacío (y entonces estoy muy interesado en sus servicios).
Esto equivale a un poco deprimente del siguiente resumen : si sus usuarios confían en una CA deshonesta, entonces ya están en uso; y no hay nada que su servidor pueda hacer para protegerlos realmente. El primer paso es enseñarles a desconfiar de la CA existente, lo que traerá protección (asumiendo que sus máquinas no están ya secuestradas), pero también "romperá Internet" desde su punto de vista.