SI utilizo un SRP para la autenticación de la aplicación cliente / servidor sin TLS. ¿Será vulnerable al ataque del hombre en medio, ya que si se usa SRP, la información pública no es realmente útil para calcular la clave de sesión?
SI utilizo un SRP para la autenticación de la aplicación cliente / servidor sin TLS. ¿Será vulnerable al ataque del hombre en medio, ya que si se usa SRP, la información pública no es realmente útil para calcular la clave de sesión?
SRP es un protocolo de intercambio de claves basado en contraseña , que implica autenticación mutua (el cliente tiene la garantía de que habló con el servidor correcto, el servidor tiene una garantía de que habló con el cliente correcto). Por definición, esto descarta a cualquier hombre en el ataque central . Esto se aplica al protocolo SRP completo ; Si observa la página de diseño , verá que el cliente y el servidor primero intercambian un par de mensajes ( I,A de la cliente, s,B desde el servidor), y luego realice algunos cálculos que produzcan la clave de sesión común K para ambos. Pero la autenticación no está completa en ese punto; como dice la página, el cliente y el servidor "aún tienen que demostrarse que sus claves coinciden", por lo que hay un par de mensajes adicionales para intercambiar.
En ese momento, el cliente y el servidor tienen "autenticación mutua" en el siguiente sentido:
K . K . (Los mensajes adicionales de "coincidencia de clave" son necesarios para que la autenticación sea explícita, pero también para que el protocolo sea sólido, los detalles criptográficos son complejos.)
Pero esto no es suficiente . De hecho, cuando desea autenticación , no solo quiere saber in abstracto que el par deseado existe y que aún no está muerto; desea autenticar una sesión , es decir, intercambiar datos posteriormente. Un atacante en la posición de hacer un ataque MitM podría dejar pasar los mensajes y luego secuestrar el medio de transporte e inyectar sus propios paquetes de datos. Para autenticar la sesión , la clave compartida K debe usarse para calcular un Código de autenticación del mensaje sobre los fragmentos de datos que el cliente y el servidor se envían entre sí. En muchos casos, también se necesitará cifrado . Se considera que la aplicación de un MAC y, posiblemente, el cifrado a los datos transmitidos de forma segura, es una tarea difícil; hay detalles .
Si implementa SRP y luego agrega una capa de transporte para los datos que computan el MAC y el cifrado y hace todo lo necesario para que la sesión sea segura (incluida la diversificación de claves para evitar que un atacante haga que el servidor hable a sí mismo; secuenciación, para evitar la reordenación de los fragmentos de datos, la terminación verificada, para evitar el truncamiento, y así sucesivamente ...), luego termina con algo que es, básicamente, TLS. TLS con SRP trata sobre el protocolo minimal que usa SRP para autenticar una sesión. Se necesitaría una situación muy especial para justificar la invención de su propio protocolo (un esfuerzo altamente arriesgado) en lugar de solo usar TLS.
Lea otras preguntas en las etiquetas passwords authentication tls