Bridging TLS handshake para dejar la clave privada en el navegador

Question

Bridging TLS handshake para dejar la clave privada en el navegador

#1 de Steffen Ullrich (3 votos)

0

Situation

Tenemos una aplicación web de una sola página que le permite al usuario arrastrar y soltar su certificado y clave privada en ella. Estos se utilizan para autenticar en el servicio web.

Aunque los navegadores pueden realizar un protocolo de enlace TLS que incluye la autenticación del cliente a través de HTTPS, solo usan los certificados instalados en el almacén de certificados del sistema operativo (por ejemplo, Chrome en macOS o MS Edge en Windows) o en el almacén de certificados del navegador (por ejemplo, Firefox) .

Sin embargo, no hay forma de suministrar un certificado / clave privada a las API de solicitud proporcionadas por el navegador según lo estandarizado por el W3C. (Por ejemplo, fetch () solo permite especificar si se deben incluir las credenciales instaladas o no.)

Pregunta

¿Es razonable implementar algún tipo de adda; ¿El servicio "TLS bridging" en nuestra situación?

Esto funcionaría de la siguiente manera:

El servicio de puente acepta el certificado por parte del cliente (por ejemplo, a través de HTTP),
... inicia de forma síncrona un protocolo de enlace con el servicio de autenticación de cliente real
... y responde transmitiendo el desafío de TLS al cliente.
El cliente puede resolver el desafío con la clave privada eliminada y enviarla de vuelta mediante una solicitud HTTP adicional
El servicio de puente puede responder al resultado del protocolo de enlace / solicitud (por ejemplo, el token de autenticación)

ACTUALIZACIÓN 1:

Controles

Las siguientes restricciones técnicas están establecidas por ahora:

solución solo para JS en la aplicación web (por ejemplo, sin Flash)
La clave privada del cliente no debe transmitirse a ningún servidor
La instalación manual del certificado en el sistema operativo / navegador no debe ser necesaria.

ACTUALIZACIÓN 2:

Desde el 20 de marzo de 2018, el W3C enumera el Estándar de autenticación web como "Recomendación del candidato" que resolvería problema descrito al ofrecer API estandarizada para realizar la autenticación del cliente. Los MDN docs también son bastante informativos sobre el uso de esa API en el estado actual.

authentication web-browser tls javascript

pregunta Leo Selig 03.04.2018 - 09:56

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication web-browser tls javascript

¿Es seguro usar un almacén de claves que almacena la contraseña como una cadena codificada de manera reversible? Usando el escritorio remoto

score 3 · Accepted Answer

No hay forma de dividir el protocolo de enlace de TLS en tres partes de la manera que usted imagina, es decir, la parte del protocolo de enlace que proviene del cliente original, parte del servicio de "puente TLS" y parte del servidor.

Una razón es que el mensaje Finished del lado del cliente no se puede construir de manera que el servidor lo acepte: el mensaje Finished necesita el secreto maestro y también un hash en todos los mensajes de reconocimiento. Pero dado que el maestro secreto solo es conocido por el cliente original y todos los mensajes de intercambio son solo conocidos por el servicio de puente TLS (ya que ha agregado mensajes al saludo de manos) ni el El cliente original ni el servicio de puente TLS tienen toda la información necesaria para construir el mensaje Finished .

Todo lo que podría hacer es crear un hombre completo en el proxy central que resulte en una conexión TLS completa entre el cliente y el servicio de puenteo y otro entre el servicio de puente y el servidor. Por supuesto, el servicio de puente tendrá que volver a crear el certificado del servidor original utilizando su propia CA y el cliente deberá confiar en la CA del servicio de puente.