Recuperar el certificado del cliente usando los resultados de Tcpdump en el certificado de longitud cero

Question

Recuperar el certificado del cliente usando los resultados de Tcpdump en el certificado de longitud cero

#1 de Thomas Pornin (5 votos)

5

Estoy intentando crear una aplicación móvil (con Fiddler ), que envía un certificado de cliente al servidor al que se conecta. Creo que capturar tráfico con Tcpdump , recuperar el certificado del cliente y usarlo con fiddler sería suficiente para evitar esto.

Sin embargo, cuando capturo paquetes utilizando Tcpdump sin un proxy, me doy cuenta de que el servidor envía algunos certificados, solicita un certificado de cliente y el cliente envía un certificado vacío (la longitud del certificado era 0 ). Después de todo el proceso SSL, los datos de la aplicación se envían normalmente, y la aplicación funciona bien después de eso. El hecho de que se acepte una longitud de certificados 0 me hizo pensar que se aceptaría cualquier certificado, pero este no parece ser el caso.

De hecho, le paso un certificado falso a Fiddler, y veo una entrada similar nuevamente (longitud del certificado 0 ), lo que me hace pensar que me falta algo sobre cómo el cliente envía el certificado.

Después del proceso SSL, obtengo un servidor Alcrypted Alert y la aplicación no funcionará en absoluto. Entonces, me pregunto, ¿por qué obtengo la longitud de un certificado 0 a pesar de que envío un certificado? Incluso si es falso, ¿no debería estar viéndolo en Tcpdump?

tls certificates proxy tcp

pregunta Spyros 23.07.2013 - 07:53

fuente

1 respuesta

Lea otras preguntas en las etiquetas tls certificates proxy tcp

¿Cuáles son las ventajas y desventajas de usar yubikey con el cifrado de hardware ssd? ¿Cuántos bytes debe tener un token de autorización? [duplicar]

score 5 · Accepted Answer

En TLS , después de presentar su propio certificado, el servidor puede solicitar un certificado de cliente (mensaje CertificateRequest ) . La solicitud contiene la lista de los nombres de CA que el servidor utilizará para validar el certificado. Luego, el cliente debe responder con un mensaje Certificate que contenga un certificado coincidente: el cliente escaneará el certificado que posee para obtener el certificado emitido, directa o indirectamente, por una CA cuyo nombre es uno de los nombres especificados por el servidor.

Si el cliente no tiene un certificado coincidente, debe enviar un mensaje Certificate con una lista vacía (que es lo que observa) (en SSL 3.0, en esa situación, el cliente omitió el mensaje Certificate en total, pero desde TLS 1.0 es obligatorio un Certificate vacío).

Cuando el cliente no presenta un certificado, depende del servidor decidir qué hacer a continuación. No obstante, el servidor puede aceptar la conexión. En la configuración de IIS, esa es la diferencia entre "solicitar certificado" y "requerir certificado". Entre los posibles comportamientos, el servidor puede aceptar la conexión en el nivel SSL, y luego recurre a un protocolo de autenticación a nivel de aplicación dentro del túnel (que, desde el exterior, aparecería como "datos cifrados de la aplicación ").

Por lo tanto, o no tiene un certificado coincidente en el lado del cliente, o el cliente no nota de que sus certificados coinciden, por ejemplo. por falta de una CA intermedia (en el caso de raíz - > intermediateCA - > entidad final, y el servidor envía el nombre de la raíz, pero el cliente solo conoce la "entidad final").