TLS permite que el certificado de cliente se use para inicializar una conexión TLS a un servidor. Sin embargo, lo mismo se puede lograr mediante:
- Inicialice la conexión TLS como un cliente anónimo con una clave privada generada aleatoriamente.
- El servidor proporciona un número aleatorio como desafío en un formulario web o encabezado HTTP.
- El cliente, por ejemplo, un navegador, utiliza la clave privada (a través de window.crypto javascript API) para generar una llamada RESTful API para identificarse en el servidor firmando el desafío y proporcionando el certificado.
¿Los dos métodos: certificado de cliente y llamada a javascript-API son los mismos en términos de seguridad?
El escenario detrás de esta pregunta es que estamos usando una clave pública de blockchain para establecer una conexión TLS. Dado que no hay un certificado de cliente firmado por la autoridad, el cliente proporciona una ruta del árbol Merkle como prueba en su lugar.
Al parecer, el servidor HTTPS no comprende el formato de dicha prueba cuando se utiliza como reemplazo del certificado del cliente, por lo que estamos modificando el servidor.
Entonces alguien plantea la pregunta: ¿hay alguna ventaja de seguridad que podamos obtener para implementar Merkle tree proof como certificado de cliente? Parece perfectamente seguro si lo implementamos en la capa de lógica de negocios comenzando con una conexión TLS anónima y luego requiere autenticación.
Comencé a darme cuenta de que hay otras ventajas para realizar la autenticación después de establecer la conexión TLS, por ejemplo. da la oportunidad de una mejor interfaz de usuario, por ejemplo, al mostrar mensajes como este "Su prueba Merkle parece apuntar a la red de prueba; solo aceptamos la prueba Merkle de la red principal".
Luego me pregunto, ¿cuál fue la razón para usar el certificado del cliente para iniciar TLS en primer lugar? ¿Por qué TLS incluye el concepto de inicializar TLS con certificado de cliente? Solo busca hacer que los sistemas sean más difíciles de usar sin ventajas de seguridad.