¿Por qué necesitamos HTTPS para contenido estático? Si podemos tener una suma de comprobación al final firmada por la clave privada, ¿eso no prueba la validez?

  

¿Por qué necesitamos HTTPS para contenido estático? Si podemos tener una suma de comprobación al final firmada por la clave privada, ¿eso no prueba la validez?

Creo que estás configurando un hombre de paja con esa pregunta. De hecho, no necesitamos HTTPS para el contenido estático, y el propósito de HTTPS no es solo demostrar la validez del contenido. Eso es solo uno de varios propósitos. El movimiento para cambiar una gran cantidad de sitios a HTTPS (incluso aquellos que ofrecen contenido estático inofensivo, como wikipedia) en el último par de años no ocurrió principalmente porque la gente estaba preocupada por obtener el contenido incorrecto; es porque a la gente le preocupaba que las agencias de tres letras espiaran a los usuarios; p.ej. El cambio a gran escala a HTTPS ocurrió principalmente por razones de privacidad (ver, por ejemplo, RFC 7258, Monitoreo generalizado es un ataque : gracias a Michael Kjörling por señalar esto).

Su idea de utilizar una suma de comprobación firmada ya está en producción en Internet: el software que descarga a menudo se verifica así. Los administradores de paquetes / sistemas de actualización de la mayoría de los sistemas operativos hacen esto, y los proyectos de software individuales lo hacen a menor escala mediante la publicación de firmas pgp / gpg junto con sus descargas de software.

Todo esto funciona independientemente de si estas descargas se envían a través de https o no, aunque https se usa a menudo además .

Está sugiriendo que agregue un tercer protocolo además de http y https, tal vez uno llamado httpv para "verificado", que integra la verificación de contenido en el protocolo pero omite el resto de ssl.

Estoy de acuerdo en que sería una ventaja proporcionar contenido estático de forma clara para que pueda almacenarse en caché. Pero esta no es una opción si le preocupan los problemas de privacidad a la luz de los programas de la comunidad de inteligencia para espiar todas nuestras comunicaciones.

  

¿Alguna razón en particular por la que no se consideren estos semi HTTP?

Asumiría que tu tercer protocolo no puede acumular mucha fuerza porque

1. ya hay soluciones que funcionan cuando realmente necesitamos verificar el contenido, y

2. Dado que gran parte de Internet ahora se encripta para proteger nuestra privacidad, parece que no habría mucho uso para otro protocolo que no protegiera contra el espionaje.

Su sugerencia es básicamente dividir el HTTPS en dos cosas: Signing-Only y Encryption: Signing-Only evita que un hombre activo en el medio inyecte su propio contenido, como etiquetas de script, y el cifrado protegería los datos confidenciales.

¿Pero quién decidiría qué es información sensible y qué no? Esto parece llevar mucho tiempo y es propenso a errores.

Por supuesto, puede declarar automáticamente que las imágenes, CSS, videos y archivos JS no son sensibles. Pero son ellos?

• Los archivos JS se utilizan para intercambiar datos
• Las imágenes y los videos pueden contener datos altamente confidenciales
• Los archivos CSS pueden proporcionar información sobre qué página específica está viendo una persona
• Todas las solicitudes pueden contener datos confidenciales en la respuesta del encabezado HTTP (como el establecimiento de cookies)

Tu idea también requeriría algunos otros cambios:

• ¿Qué pasa con HSTS? Fuerza todo el tráfico a través de HTTPS y se recomienda encarecidamente. ¿Contaría su HTTP de solo firma? ¿Cómo funcionaría eso en la práctica?
• ¿Qué pasa con la usabilidad? La interfaz del navegador debería indicar al usuario qué "modo" se está utilizando actualmente. Y requeriría una mayor educación del usuario sobre lo que significan los modos, y cuándo es apropiado el modo. Esto generará mucha confusión (los usuarios ni siquiera comprenden todos los elementos de la interfaz actual, como el candado o las distintas advertencias).
• De alguna manera, debería indicar al servidor de almacenamiento en caché del ISP que está solicitando este archivo. No puede simplemente tener la solicitud al servidor a través de HTTP, ya que eso podría filtrar cookies y otros datos confidenciales. O debería especificar que nunca se enviarán cookies a estos archivos no confidenciales. Pero, ¿cómo lo harías de manera confiable? Claro, podrían servirse desde un dominio diferente, pero eso requiere un importante rediseño de los sitios web existentes. ¿Y qué pasaría si esos archivos no confidenciales estuvieran protegidos por algún tipo de autenticación?

Aparte de eso, los beneficios de este enfoque parecen bajos. Por lo que estoy leyendo, los ISP rara vez almacenan en la memoria caché porque los CDN ya se encargan de eso.

tl; dr : el enfoque violaría la privacidad de los usuarios e introduciría problemas de seguridad debido a problemas de uso tanto para el usuario final como para el desarrollador.

La implementación de algún tipo de suma de comprobación funcionaría, sí. Pero usar TLS es mucho más fácil.

En general, también se recomienda utilizar protocolos estándar a menos que tenga una buena razón para no hacerlo.

Finalmente, https proporciona una variedad de otras ventajas. Dentro de los límites del sistema de CA, sabe que está recibiendo el archivo de quien cree que está. Y proporciona privacidad a sus usuarios, evitando que los observadores vean qué URL específicas solicitan.

Hay algunos problemas de seguridad que se me ocurren.

Reproducción y sustitución

No hay nada que impida que un hombre en el medio reemplace un recurso firmado con otro recurso firmado (capturado anteriormente). Por ejemplo, podría hacer que aparezca un botón IR verde donde debería estar el botón DETENER, causando que usted salga de un precipicio. O puedo hacer que parezca que su transferencia de efectivo ha fallado, de modo que la envíe una y otra vez y me paguen varias veces.

Si parte del contenido estático de un sitio es un archivo Javascript, quizás pueda intercambiarlo con un archivo Javascript diferente del mismo sitio. Si soy inteligente, tal vez pueda encontrar uno que tenga los mismos nombres de funciones pero que haga cosas diferentes o que carezca de ciertas validaciones.

Redirección

Podría interceptar tu solicitud de una imagen y responder con un redireccionamiento 302 a una URL cuyos parámetros de cadena de consulta comprenden un ataque XSRF.

Pérdida de privacidad

Un pirata informático que supervisa su tráfico puede determinar qué páginas está visitando al examinar el patrón de solicitudes http para recursos estáticos.

DoS mediante envenenamiento de caché

Un pirata informático, que trabaja con un hombre en el medio, sustituye un archivo no válido por una de las respuestas. El proxy almacena en caché el archivo. Los navegadores que intenten utilizar el recurso almacenado en la memoria caché encontrarán que falla la validación y mostrarán un error, sin medios fáciles de evitar el problema.

P.S. Problema de rendimiento

Además, hay un problema de rendimiento: los recursos que están sujetos a una suma de comprobación no podrán representarse progresivamente, ya que se requiere que todo el BLOB calcule la suma de comprobación. Por lo tanto, tus imágenes aparecerán más lentas y tu película no comenzará hasta que todo haya terminado.

Esto se resuelve en parte con integridad del sub-recurso . Usted sirve la página principal a través de HTTPS, y esto incluye los metadatos / hashes del sub-recurso, los sub-recursos se pueden recuperar a través de HTTP para ser almacenados por proxy de ISP o sobre HTTPS para ser almacenados en caché por un CDN y puede estar seguro de que el recurso no está atestado. por los intermediarios, siempre que el hash coincida.

Sin embargo, los navegadores aún consideran que los sub-recursos entregados de esta manera son contenido mixto porque cualquier modelo que permita el almacenamiento en caché de ISP carece de confidencialidad. En cambio, el modelo que se está impulsando hoy en día es que los propietarios del sitio configuren una CDN para realizar el almacenamiento en caché de la red perimetral, por lo que el propietario del sitio paga los cachés de los bordes en lugar de los usuarios. Esto también es un mejor augurio para el ISP como modelo de neutralidad de la red de sistemas sin sentido.

  

Si podemos tener una suma de comprobación al final firmada por la clave privada, ¿no probará eso la validez? ... ¿Alguna razón particular por la que no se consideren estos semi HTTP?

Probablemente porque es trivial eliminar la firma y volverás a los contenidos sin firmar. El modelo SRI, por otro lado, requiere que el documento principal indique cuándo se espera que el sub-recurso esté asegurado.

Debe entenderse que los proveedores de navegadores no han tenido más que malas experiencias con "middleboxes", y se han decidido por el cifrado de extremo a extremo como la mejor manera de evitar que interfieran. Esta es la razón por la que, por ejemplo, se niegan a implementar texto claro HTTP / 2.0. Por la misma razón, es muy poco probable que alguna vez se adopte algo en la línea de su idea.

Existen técnicas para firmar el contenido del sitio web estático, especialmente HTML, por ejemplo:

• enlace
• enlace

Tales iniciativas aún no se han hecho populares. Sospecho que esto es por tres razones:

• son difíciles de implementar;
• el cambio cultural hacia un desarrollo web más seguro (del cual el uso generalizado de HTTPS es una faceta) aún estaba en su infancia cuando se propusieron por primera vez;
• muchos desarrolladores web no saben cómo utilizar las herramientas de OpenPGP, y mucho menos poseen una clave de firma de OpenPGP generada de forma segura y almacenada de forma segura.

Sin embargo, estas técnicas constituyen en principio un mecanismo excelente para verificar la integridad de los recursos estáticos en los sitios web.

Sin embargo, incluso si dicha firma de recursos web estáticos fuera universal, seguiría siendo un beneficio la implementación de HTTPS: confidencialidad . La firma por sí sola no proporcionaría esto, pero el cifrado proporcionado por HTTPS lo proporcionaría. (Al menos, HTTPS proporcionaría confidencialidad siempre que la especificación aplicable para HTTPS no tenga errores críticos y se haya implementado correctamente).