Cómo verificar el certificado con muy poca información

4

Supongamos que hay un servidor y un cliente y desea conectar esos dos. El servidor tiene un certificado autofirmado y, antes de establecer la conexión por primera vez (inscripción), el servidor crea un certificado de cliente y una contraseña de un solo uso para el cliente específico. (iniciado en el servidor)

El administrador tiene ambas máquinas frente a él, y luego escribe la contraseña de un solo uso en el cliente (asume el transporte seguro del token al cliente). El cliente luego se conecta al servidor (https) y, en caso de éxito, se identifica con la contraseña de un solo uso. El servidor luego envía el certificado de cliente al cliente.

La inseguridad está en el momento de la primera conexión. Como el cliente no conoce el certificado del servidor (y está autofirmado), alguien podría secuestrar la conexión y redirigir al cliente a un "servidor incorrecto" y enviar la contraseña de un solo uso a ese sin siquiera saberlo. (Lo más probable es que la intranet esté bien, el peligro real es que esto se haga a través de Internet).

Hay una manera de solucionar esto completamente: no solo le de al cliente una contraseña única, sino también la huella digital del certificado del servidor. Desafortunadamente, esto no se puede hacer en este escenario, y solo puedo transferir 4 a quizás 6 u 8 bytes con el fin de validar el certificado.

Sé que esto no establece una seguridad completa, pero supongo que es mejor que no comprobar, ¿verdad? ¿Qué tan fácil sería para un atacante crear un certificado que tenga la url correcta y coincida? Diga los primeros 4-8 caracteres de la huella digital. ¿Existe alguna forma de hacerlo más seguro con solo 4-8 bytes?

    
pregunta Flo 10.01.2013 - 15:02
fuente

2 respuestas

8

Una solución teórica es hacer una primera conexión con TLS-SRP . Esto es SSL, pero con un conjunto de cifrado especial que no utiliza ningún certificado; en cambio, el cliente y el servidor se autentican entre sí con respecto al conocimiento de una "contraseña" común; esto incluso tolera contraseñas de baja entropía porque es inherentemente inmune a los ataques de diccionario sin conexión . Dentro de esta conexión inicial, el servidor debe transmitir una copia de su certificado "normal", que se utilizará para otras conexiones. Esta estrategia se usa en algunos casos para emparejar dispositivos Bluetooth .

Lamentablemente, no todas las bibliotecas SSL / TLS conocen SRP. GnuTLS sí lo hace.

Si puede obtener los primeros 8 bytes verdaderos de la huella digital (no 8 caracteres hexadecimales ), esto puede ser suficiente. Generar un certificado falso que coincida con los primeros 8 bytes (es decir, 64 bits) de la huella dactilar es tecnológicamente factible, pero costoso (piense en unos pocos cientos de PC en funcionamiento durante algunos meses).

    
respondido por el Thomas Pornin 10.01.2013 - 15:23
fuente
1

El servidor no debe crear el certificado del cliente, el cliente debe crear el certificado y enviar la clave privada al servidor a través del canal SSL que describió. En la situación que describe, el atacante puede pretender ser el servidor (a quien el cliente no conoce porque el certificado está autofirmado) y luego tomar la contraseña para enviar la solicitud al servidor. El atacante puede mantener la clave privada y reenviarla al usuario, y ni el servidor ni el usuario son conscientes de un problema.

Si, en cambio, el cliente hace el certificado y envía la clave pública al servidor y firma la clave pública con su clave privada, entonces el atacante aún puede interceptar la contraseña y enviar su propia clave pública, sin embargo, el cliente no podría Conéctate y se detecta la intrusión. Esto no funciona si el atacante puede fingir ser el servidor de forma persistente, ya que puede ocultar el hecho de que el cliente no se está conectando al servidor real.

    
respondido por el AJ Henderson 10.01.2013 - 15:25
fuente

Lea otras preguntas en las etiquetas