Verifique que una segunda conexión TLS proviene del mismo cliente

3

Me gustaría implementar una especie de esquema de confianza en el primer uso (TOFU) con TLS:

  • Un cliente crea una clave y un certificado autofirmado.
  • El cliente se conecta al servidor con este certificado.
  • El servidor acepta la conexión y almacena algo sobre el cliente
  • Suponiendo que esta primera conexión no fue MITM'd, quiero poder verificar que la próxima conexión proviene del mismo cliente.

¿Es esto posible? Y si es así, ¿qué es ese algo que tengo que almacenar desde la primera conexión para poder verificar la segunda conexión?

En la práctica, estoy utilizando la biblioteca Golang TLS, así que creo que esta es la información que tengo sobre el certificado de conexión.

    
pregunta AndreKR 06.03.2017 - 14:25
fuente

2 respuestas

3

Ya que está utilizando TLS con certificados de cliente y desea detectar si el mismo cliente con el mismo certificado se conecta nuevamente, simplemente puede almacenar el certificado de cliente o la clave de publicación contenida en el certificado, o una huella digital (hash) de estos. Dado que, según su descripción, la clave y, por lo tanto, el certificado se generan en el cliente y son únicos para el cliente, cualquiera de las características mencionadas debe identificar de forma única al cliente. Y dado que solo el propietario de la clave privada (es decir, el cliente) puede usar el certificado coincidente para la autenticación contra el servidor, también es imposible que solo el conocimiento de la huella dactilar o el certificado permita que un atacante se haga pasar por el cliente.

    
respondido por el Steffen Ullrich 06.03.2017 - 20:16
fuente
5

En lugar de diseñar su propio esquema para esto, puede buscar en JWT utilizando x509: enlace .

Oauth también tiene este tipo de opción (creo), pero no puedo encontrar documentación decente.

Creo que hay algunos aspectos de su solución que parecen problemáticos en la actualidad, en particular, en lugar de almacenar algo en el servidor por cliente, usar x509 significa que solo necesita validar el certificado presentado por el cliente que se emite correctamente, en lugar de Hacer verificaciones más complejas.

No hay necesidad (AFAIK) de que los certificados que emita a sus clientes sean válidos fuera de su propio entorno (es decir, puede usar su propia CA para esto), por lo que podría tener su flujo como:

  • el cliente solicita un certificado basado en un CSR que genera (similar a Oauth)
  • si la solicitud del cliente se autentica correctamente, la CSR se procesa en un certificado válido para sus necesidades
  • el cliente almacena este certificado y lo presenta cuando es necesario
  • el servidor valida que el certificado es válido y extrae su clave pública para sus propias necesidades (si las hay).

Entonces, sí, lo que propones puede ser posible, pero parece que ya hay algunos esquemas establecidos que proporcionan un enfoque similar, y que podrían valer la pena analizarlos.

    
respondido por el iwaseatenbyagrue 06.03.2017 - 14:59
fuente

Lea otras preguntas en las etiquetas