Sitio web: Autenticación de clave precompartida

7

Tenemos esta aplicación web con datos de gran valor (comerciales).

Todas las comunicaciones se cifran a través de TLS / SSL. Si bien considero que este es un protocolo realmente seguro, aún puede verse comprometido si alguien logró instalar un certificado de CA malicioso en mi computadora.

Ya que tenemos la infraestructura, nos gustaría fortalecer la autenticación mutua a través de una clave previamente compartida (a través de SMS).

(No quiero inventar algo, pero como lo veo, el PSK debería usarse para cifrar el flujo subyacente. Tal vez el SSL circundante podría incluso ser una sobrecarga, pero nuevamente, no estoy intentando inventar mi propio protocolo)

¿Alguien sabe si los navegadores son compatibles con el cifrado / autenticación de clave precompartida? Tal vez a través de un plugin? Busqué en la web y no encontré nada sobre el soporte del navegador.

    
pregunta jrnv 15.09.2013 - 12:04
fuente

2 respuestas

10

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.

    
respondido por el Tom Leek 15.09.2013 - 15:10
fuente
1

Como se mencionó anteriormente, probablemente sería más fácil agregar una capa de seguridad mediante el uso de VPN. Echa un vistazo a por ejemplo enlace

Una vez que haya creado y compartido sus claves y configurado su VPN, puede asegurarse de que su Aplicación se conecte a la IP de la VPN de su servidor en lugar de a la IP pública (Internet). Con esta configuración, ni siquiera necesita configurar proxies ni nada.

    
respondido por el Echsecutor 26.05.2014 - 17:48
fuente

Lea otras preguntas en las etiquetas