Quiero poder demostrar que un contenido dado devuelto por un servidor HTTPS fue de hecho servido.
He revisado todo el protocolo TLS y descubrí que puedo usar ServerKeyExchange para obtener la firma del servidor de una cadena aleatoria que puedo enviar al servidor, para iniciar el Diffie-Hellman intercambio.
Sin embargo, no he encontrado la manera de obtener la firma del contenido del contenido que está sirviendo .
¿Hay alguna manera de hacerlo?
En TLS, ni el cliente ni el servidor firman ningún contenido. Las firmas criptográficas que se utilizan en el protocolo de enlace inicial están destinadas a la autenticación : el cliente obtiene cierta garantía de que habla con el servidor correcto, y (si se usan certificados de cliente) el servidor obtiene alguna garantía de que Habla con el cliente correcto. Sin embargo, ninguna de estas garantías es transferible: aunque el cliente sabe que los datos que obtiene provienen del servidor, el cliente no obtiene ninguna prueba que pueda mostrarse a un tercero. Eso es autenticación, no no repudio.
Incluso si el cliente registra todo lo relacionado con la conexión completa (todos los bytes de datos enviados y recibidos, todas las claves criptográficas negociadas, etc.), esto prueba solo una cosa: que, en algún momento no especificado, el servidor era, de hecho, un servidor TLS, y ha estado involucrado en al menos una conexión TLS. Todo lo demás, incluidos todos los datos recibidos y enviados por el servidor, podría haber sido fabricado posteriormente, por lo que no puede ser una prueba (en el sentido criptográfico).
Por lo tanto, no ha encontrado una manera de "obtener la firma del servidor del contenido que está sirviendo" por la razón de que esta firma no existe . Si desea que el servidor firme cosas, esto debe organizarse a nivel de protocolo, dentro del túnel TLS: haga que el servidor firme debidamente los datos y envíe la firma como parte de lo que TLS llama "datos de la aplicación ". Por supuesto, el servidor tendrá que estar al tanto de la operación, y esto no es parte del procesamiento normal de TLS (HTTPS).
De forma alternativa, haga que un alguacil u otro funcionario similar se conecte al servidor, obtenga los datos y firme ellos mismos, garantizando así (de manera legal) que el servidor efectivamente sirve el contenido de estos datos.
RFC4346 :
Los objetivos del protocolo TLS, en orden de prioridad, son como
sigue:
Seguridad criptográfica: TLS debe usarse para establecer un seguro conexión entre dos partes.
Interoperabilidad: los programadores independientes deberían poder Desarrollar aplicaciones utilizando TLS que puedan intercambiarse con éxito. Parámetros criptográficos sin conocimiento del código del otro.
Ni el servidor ni el cliente firman los datos por sí mismos. Solo firman parte del apretón de manos con una suite específica. Eso significa que puede demostrarle a un tercero que se produjo un intercambio de manos con un determinado servidor y qué datos se intercambiaron en ese acuerdo.
También, desde aquí , puede leer:
El TLS estándar no tiene soporte de no repudio.
Lea otras preguntas en las etiquetas cryptography tls diffie-hellman