Integridad del sub-recurso versus firma

8

El borrador de especificaciones para la integridad del sub-recurso es sencillo :

  

Este documento especifica dicho esquema de validación, extendiendo dos HTML   Elementos con un atributo de integridad que contiene un criptográfico.   hash de la representación del recurso que el autor espera cargar.

Tal solución es muy estática. Si un proveedor confiable desea cambiar su JavaScript, debe actualizar el hash de integridad y distribuirlo a todos los usuarios posibles. En esencia, el objeto en esa dirección nunca debería cambiar, nunca. Si actualiza su recurso, debe darle una nueva dirección junto con su nuevo hash. (Lo que me hace pensar en IPFS , pero estoy divagando). En el (peor) caso, el desarrollador web inteligente pero ignorante generará dinámicamente el hash de cualquier documento que esté alojado en un momento dado.

Sin embargo, soy escéptico de este enfoque: puedo enviarle un documento firmado con mi clave privada y usted, al tener mi clave pública, puede confiar en el historial de ese documento tanto como confía en que mi clave pública sea mía . ¿No hay forma de aprovechar la firma de claves asimétricas para proporcionar una mejor experiencia para los desarrolladores web sin socavar la seguridad?

Hipotéticamente, ¿cuál sería el impacto en la seguridad si (en lugar de SRI) el siguiente comportamiento se incluyera en los agentes de usuarios web?

Una respuesta del servidor web principal incluiría una lista de claves públicas asignadas a sus sub-recursos. Se espera que esos recursos sean documentos firmados. Si no, o si la firma no coincide con la clave esperada, el agente de usuario tomaría medidas de protección similares a las que propone el borrador de SRI.

En última instancia, estoy tratando de entender cómo proporcionar hashes estáticos de cada documento es mejor que la firma clave en este caso.

    
pregunta kojiro 10.12.2015 - 17:23
fuente

1 respuesta

1
  

Si un proveedor confiable desea cambiar su JavaScript, debe actualizar el hash de integridad y distribuirlo a todos los usuarios posibles.

No si la política de almacenamiento en caché significa que el remitente no se almacenará en caché durante más tiempo que el árbitro. Es otro argumento sólido para usar largos tiempos de caducidad para contenido estático e inyectar una variable en la URL. Creo que (querría dedicar un tiempo a pensar y probar) que usar extend_cache de mod_pagespeed entregaría el resultado deseado sin tener que esperar a que los desarrolladores del navegador implementen SRI. Si el manejo inteligente 404 en el origen (es decir, la creación de una respuesta en caché en lugar de un 404), entonces el trabajo pesado podría realizarse en el CDN en lugar de en el origen.

Mi pensamiento inmediato al leer sobre SRI fue que debería ser una extensión de CSP que indique qué recursos pueden hacer referencia a un elemento de contenido (en lugar de especificar a qué elementos de contenido se puede hacer referencia a un recurso). Sin embargo, en la IME, la mayoría de los navegadores (Firefox es una excepción notable) no tienen un manejo de referencias a prueba de balas. La única forma en que puedo ver que el cifrado asimétrico sea de alguna utilidad sería asociarlo con el mecanismo de referencia.

    
respondido por el symcbean 18.01.2016 - 13:30
fuente

Lea otras preguntas en las etiquetas