Si un servidor tiene una clave pública conocida y se realiza un intercambio Diffie-Helman con esa clave, ¿hay algún beneficio en autenticar al cliente antes de establecer un canal seguro en lugar de después de establecer el canal seguro? Me parece que firmar solo un lado del intercambio todavía impide un ataque de hombre en el medio.
Inspirado por enlace
La autenticación del cliente es para el beneficio del servidor. Prevenir a un hombre en el medio es un asunto distinto.
Si el intercambio de claves utiliza DH con una firma por parte del servidor (en relación con una clave pública que se conoce por el cliente ), el cliente está protegido de un hombre -en el medio: el cliente tiene una fuerte idea de con quién debería hablar, y la firma del servidor evita que un atacante se haga pasar por el servidor de manera alguna (por ejemplo, como un "hombre en el medio" , que es solo un tipo específico de suplantación).
Sin la autenticación del cliente, el servidor no sabe quién lo está contactando. El resto del protocolo (por ejemplo, SSL / TLS ) seguirá brindando protección contra ataques en el siguiente sentido: será el el mismo cliente a lo largo de la sesión, y ninguna otra parte puede espiar el contenido de los datos o alterar los datos de forma no detectada. Como tal, un "hombre en el medio" (como en: un atacante que actúa como un relevo, descifrando y reencriptando datos sobre la marcha) se evita, porque el cliente ha verificado La firma del servidor, y por lo tanto usó la clave Diffie-Hellman "correcta", manteniendo a cualquier atacante fuera del intercambio de claves.
La autenticación del cliente como una firma, calculada por el cliente con su propia clave privada y correspondiente a una clave pública conocida por el servidor, podría ayudar a prevenir a un hombre en el medio en un devious situación en la que el cliente no (estúpidamente) verifica la firma del servidor. Nada puede evitar que este cliente morónico se conecte a un servidor falso, ya que no verifica nada y, por lo tanto, puede malversarse a voluntad. Sin embargo, la autenticación del cliente es suficiente para que el servidor se asegure de que si el cliente habla con él, lo hará de manera segura.
El punto clave aquí es una cuestión de definición. ¿Qué es un "hombre en el medio"? Este es un caso en el que un atacante se hace pasar por el interlocutor deseado (para que sea un "medio verdadero", el atacante se hace pasar por el servidor con respecto al cliente y el cliente con respecto al servidor). Esto tiene sentido solo en la medida en que hay un "compañero previsto". Si al servidor no le importa quién lo está contactando, entonces no hay una noción de "hombre en el medio".
En el escenario habitual de HTTPS, el cliente se autentica a través de una contraseña: el cliente necesita asegurarse de hablar con el servidor correcto al principio (usando el certificado del servidor) porque el cliente sí No desea enviar su contraseña a nadie. El servidor solo quiere tener continuidad : si obtuvo una contraseña correcta a través de un túnel SSL, entonces el túnel es bueno y seguirá siéndolo.
Bueno ... sí, el beneficio es exactamente eso: autenticar al cliente.
En el caso de uso principal de hoy, el certificado del servidor se utiliza para autenticar el servidor ("Verisign dice que esto realmente es amazon.com") y para configurar el cifrado (evitando la indagación y el uso de intermediarios) .
Debido a que rara vez se usa, las personas no piensan en la capacidad de autenticar al cliente. Hay una razón práctica para esto, que es que un "usuario" cliente (humano) puede acceder al servidor desde cualquier "máquina" (computadora) del cliente, y si se usan claves de cliente deben ser distribuidas de manera segura a todos ellos, las máquinas cliente deben ser relativamente confiables, etc. etc. Pero existen escenarios sí en los que usar la autenticación de cliente (SSL) tiene sentido.
Si alguna vez se hubieran quitado las tarjetas inteligentes, entonces las verías por todas partes. Pero no lo hicieron. (O simplemente no, todavía no lo sé).
La autenticación del servidor solo asegurará al cliente que está hablando con el servidor. Asegurará al servidor que el cliente que realizó el protocolo de enlace es el cliente que realiza la comunicación. No le da al servidor ninguna otra información; en otras palabras, el servidor no sabrá quién es el cliente.
Para algunos casos, puede estar bien, por ejemplo, si el inicio de sesión se realiza a través del nombre de usuario / contraseña después de configurar la sesión.
No es lo suficientemente bueno si tiene una situación que requiere autenticación del cliente a través de una prueba criptográfica de clave privada. En esos casos, deberías agregar una transmisión de nivel superior donde el cliente firmó algo o deberías requerir la autenticación del cliente durante la configuración de la sesión SSL.
Todo depende de la aplicación.
Lea otras preguntas en las etiquetas authentication cryptography digital-signature tls key-exchange