¿por qué una autenticación de cliente no se realiza comúnmente en el protocolo TLS?

¿Qué es la autenticación? Esto garantiza que quienquiera que se encuentre en el otro extremo del túnel sea en quién crees . Realmente depende del tipo de identidad que quieras usar.

Para la mayoría de los sitios web, la noción interesante es continuidad . Realmente no les importa quién está conectado; de hecho, el punto de un sitio web debe ser legible por todos . El tipo de autenticidad que un sitio web desea lograr es asegurarse de que dos solicitudes sucesivas sean realmente del mismo cliente (quien sea ese cliente). Esto se debe a que la experiencia del sitio web es la de una sucesión lógica de páginas, impulsada por las acciones del usuario (los enlaces en los que hace clic), y la intromisión con ese marco similar a una película es lo que el atacante busca. El usuario y los diseñadores del sitio web piensan en términos de sesiones y el atacante quiere secuestrar la sesión.

Esta autenticidad se logra mediante varios mecanismos:

• Las solicitudes HTTP sucesivas del mismo cliente pasan por la misma conexión (con la función "keep-alive").
• SSL ofrece un mecanismo de reanudación de sesión, que reutiliza la clave compartida negociada (ese es el "protocolo de intercambio abreviado" descrito en la sección 7.3 de SSL / TLS estándar ).
• La solicitud HTTP puede incluir una cookie que el servidor elige; por lo general, un valor aleatorio, específico del usuario, se envía como una cookie al usuario y, al verlo regresar en solicitudes posteriores, el servidor está convencido de que las solicitudes provienen del mismo usuario.

La cookie es suficiente para garantizar la continuidad.

¿Qué valor adicional agregarían los certificados de cliente? Bueno, no mucho. Certificados son una forma de distribuir enlaces de clave / nombre. En su mayoría, hay tres escenarios donde los certificados de cliente (en un contexto web) son relevantes:

1. El servidor web necesita una noción extendida de identidad de usuario, que está definida por alguien más . Por ejemplo, imagine un servicio gubernamental al que puedan acceder los ciudadanos, pero solo después de una autenticación adecuada, por ejemplo. Un sistema electoral en línea. Lo que hace que el ciudadano, con su nombre definido y fecha de nacimiento, sea administrado por el Estado en general, pero no es la misma parte que la que administra el servicio. Los certificados de los clientes son una forma de transportar la autenticación desde la PKI que emitió el certificado al ciudadano, al sistema de elección en línea que no tiene derecho alguno a decir quién se llama, pero que, sin embargo, debe mantener registros claros de quién se conecta.

2. El diseñador del sistema tiene poca confianza en la robustez de los navegadores web existentes. Si el navegador de un usuario es secuestrado, entonces la cookie secreta puede ser robada y el usuario básicamente se ha perdido para siempre. Por otro lado, si el usuario tiene una tarjeta inteligente y esa la tarjeta inteligente almacena una clave privada (que se usa en combinación con un certificado de cliente), entonces un secuestro completo del navegador sigue siendo un gran problema , pero está más contenido : dado que la tarjeta inteligente realizará un seppuku honorable en lugar de dejar que se revele la clave privada más valiosa, la situación puede recuperarse. Una vez que se ha realizado el formato obligatorio y la reinstalación, las cosas están seguras una vez más.

3. El sitio web no solo quiere autenticidad, también desea obtener no repudio . El no repudio es un concepto legal que necesita algún apoyo de las partes técnicas del sistema, y ese soporte es firmas digitales . Estamos fuera de lo que proporciona SSL / TLS, aquí. De ninguna manera, la autenticación de un cliente SSL / TLS puede ser una prueba que podría usarse para resolver algún conflicto legal entre el usuario y el servidor mismo (un servidor bancario no puede mostrar la transcripción de la conexión y decir "vea, ese usuario realmente me pidió que comprara estas acciones a ese precio ", porque el banco podría fácilmente haber fabricado la transcripción completa). Para tales cosas, uno necesita certificados de cliente y algún código del lado del cliente que utiliza el certificado para firmar los datos reales. Sin embargo, una vez que se ha realizado el arduo trabajo de emitir certificados a los clientes, tiene sentido usarlos solo para HTTPS.

En el caso común de un servidor web, no se aplica ninguno de estos escenarios. Por lo tanto, los certificados de cliente no se utilizan, ya que plantearían problemas prácticos sin agregar ningún valor adicional. Esa sería una solución en busca de un problema.

La razón principal es que el 95% de los usuarios de Internet no tienen idea de qué es un certificado del lado del cliente, y mucho menos cómo usar uno. Algunos usuarios apenas pueden administrar el uso de nombres de usuario y contraseñas, y la mayoría aún no se molesta con la autenticación de dos factores. También es una molestia instalar un certificado de cliente en dispositivos separados (computadora de escritorio, computadora portátil, tableta, teléfono inteligente, etc.) para la autenticación en un solo servicio.

Entonces, para una lista rápida:

• Ignorancia. La gente simplemente no sabe qué es o por qué es útil.
• Comodidad. No se debe molestar a las personas para que configuren su dispositivo para usar certificados de clientes.
• Soporte. Si la gente todavía tiene que solicitar asistencia técnica por teléfono cuando olvida su contraseña o no puede iniciar sesión, ¿puede imaginar cuántas llamadas de soporte se necesitarán si tienen que instalar un certificado de cliente? ? Este problema se multiplica aún más por la caída de la cuota de mercado de Internet Explorer, por lo que el personal debe estar capacitado para guiar a los usuarios a través de la instalación en IE, Firefox, Chrome, Opera, Safari, etc., además de varios dispositivos móviles.
• Complejidad. Se requiere un código adicional del lado del servidor para validar el certificado en relación con una cuenta de usuario.
• Prevalencia. Ningún sitio importante los está utilizando en-mass todavía, así que nadie más lo hará. Me doy cuenta de que esto es un catch-22, pero la adopción de la tecnología a menudo sí lo es.
• Complacencia. La mayoría de los proveedores asumen que las contraseñas (o 2FA) son lo suficientemente sólidas para sus propósitos, incluso cuando dichos proveedores están protegiendo información altamente sensible / crítica como datos financieros.

Entonces, aunque sería bueno ver los certificados del lado del cliente a gran escala, realmente no veo que esto suceda a menos que un evento serio empuje a los proveedores a hacerlo.

El cliente está tratando de llegar a un servidor específico, identificado en la URL. Así que el cliente necesita autenticar el servidor.

Por otro lado, en la mayoría de los usos de HTTPS, cualquier cliente puede contactar al servidor. El servidor no tiene ningún conocimiento previo del cliente. Así que no hay nada contra lo que el servidor pueda autenticar al cliente. El servidor quiere autenticar al usuario, no a la máquina cliente.

En una configuración de Internet, el cliente puede estar detrás de un proxy, en una dirección IP dinámica, etc. No hay nada que el servidor quiera verificar. El único punto de autenticar al cliente sería registrar su identidad para usos futuros, ya sea con fines forenses o para rastrear a los clientes a través de múltiples conexiones. Dado que los usuarios pueden conectarse desde varias máquinas, no tiene mucho sentido rastrear las máquinas cliente. Registrar las identidades de los clientes solo es muy útil para identificar clientes o usuarios malintencionados después del hecho (es probable que el atacante haya generado un certificado que no proporcione información útil), no vale la pena gastar ningún esfuerzo.

En una configuración de intranet, donde solo los clientes conocidos deben conectarse al servidor, la autenticación del cliente es útil y se usa.

En casos como Gmail, Yahoo y otras aplicaciones web que utilizan PKI para autenticar servidores, la autenticación del cliente no se realiza mediante certificados, sino que utiliza una autenticación más simple, como contraseñas de usuario / nombre. Piensa sobre esto. Su navegador puede almacenar x número de certificados para las diversas CA y los sitios web que existen. ¿Pero puede Gmail mantener certificados para sus millones de usuarios? Simplemente no es escalable.

Esta es una respuesta muy simplificada en cuanto a por qué los certificados de cliente no se usan. Sin embargo, cuando se SSH en un servidor, los certificados de cliente se utilizan / tal vez.