¿La recuperación de HTTPS, entre sus otros efectos, firma un documento? [duplicar]

No, un servidor SSL no firma lo que devuelve. Las operaciones que utilizan claves asimétricas y pueden calificar como las firmas ocurren durante los pasos iniciales de la conexión (el "apretón de manos"), antes de que se envíen los datos del aplicativo, por lo que estas operaciones no pueden vincular lógicamente a nadie con el contenido de dichos datos del aplicativo.

Hay una posible fuente de confusión, que debe ser eliminada: durante el curso del uso de la conexión, todos los datos aplicativos serán cubiertos por un MAC . Sucede que algunas documentaciones descuidadas pero generalizadas se refieren incorrectamente a MAC como "firmas". Sin embargo, no son firmas, no en el sentido de "prueba oponible". En un MAC, el valor secreto necesario para generar el MAC es idéntico al valor necesario para verificar el MAC; esto implica que quienquiera que pueda verificar el MAC también tiene, por este hecho, el poder de forjar el MAC. Por lo tanto, un MAC no puede ser una "firma" en el sentido que usted desea.

Dada una copia del certificado del servidor, que es fácil de obtener (por definición, el servidor lo envía a cualquier cliente conectado), es fácil compilar desde cero todos los paquetes TCP y los registros completos de conexión correspondientes a un SSL falso La conexión que no puede puede distinguirse de una conexión genuina. Esto se ve fácilmente, matemáticamente, al ver cómo funciona el protocolo: con un simple intercambio de claves basado en RSA (el caso más común), el cliente genera una clave aleatoria (el "secreto maestro previo") y la cifra con la clave. clave pública del servidor Solo el servidor puede hacer el descifrado, pero el cliente también tiene ese secreto pre-maestro: ¡lo generó! Por lo tanto, es trivial para el cliente emular todos los cálculos que el servidor realizaría en esa situación.

Si una conexión falsa completa e indistinguible, con contenidos elegidos arbitrariamente, se puede construir desde cero sin siquiera involucrar al servidor, cualquier rastro registrado de una conexión no puede servir como firma de ninguna manera. Tal rastro ni siquiera prueba que el servidor SSL exista en absoluto.

HTTPS no firma un documento; no proporciona ninguna declaración jurada duradera sobre la procedencia, la legitimidad o la validez del documento.

Una firma es una modificación o una descripción verificable de un documento que se puede usar más adelante para validar el documento o el hecho de la autoría o revisión de ese documento por parte de una entidad. Como tal, debe tener un efecto duradero en la firma: debe acompañar el documento en sí mismo a medida que ese documento se transmite. HTTPS es simplemente un transporte que no altera ni proporciona una validación externa duradera de lo que transfiere.

Piénselo en términos del mundo real: no importa si envío un documento a través de USPS, FedEx o si le pago a un mensajero para que se lo entreguen personalmente. Todos esos son solo métodos de transporte. Si olvido firmar el documento, ninguno de estos transportes agregará una firma significativa al documento. Incluso si tuviera una confirmación de entrega, eso prueba que el documento llegó, no implica ninguna firma ni validación si no los adjunté al documento antes de enviarlo.

Como ya se mencionó en los comentarios, el protocolo HTTPS no no firma un documento. Simplemente utiliza el protocolo SSL / TLS para cifrar y descifrar en la capa de transporte del modelo OSI, usando un certificado ( que contiene la clave pública utilizada para cifrar / descifrar datos en clientes) de la Infraestructura de clave pública (PKI) .