Solucionamos el problema de contenido mixto con reescrituras HTTPS automáticas

Cloudflare pretende poner fin al Internet sin cifrar. Pero la web tiene el problema del huevo y la gallina al cambiarse a HTTPS.

Hace mucho tiempo era difícil, caro y lento configurar un sitio web que funcionara con HTTPS. Luego aparecieron servicios como Universal SSL de Cloudflare, que cambia de http:// a https://, de forma tan fácil como hacer clic en un botón. Con un clic, se servía un sitio mediante HTTPS con un certificado SSL (Secure Sockets Layer, en español, capa de sockets seguros) gratuito recién acuñado.

Hala.

De pronto, el sitio web está disponible mediante HTTPS y, aún mejor, es más rápido porque puede aprovechar el último protocolo web HTTP/2.

Por desgracia, la historia no termina ahí. Muchos sitios que por lo demás son seguros sufren el problema del contenido mixto. Y contenido mixto significa que el icono del candado verde no se mostrará en un sitio https:// porque, de hecho, no es realmente seguro.

El problema es este: si un sitio de Internet con https:// incluye cualquier contenido de un sitio web (incluso propio) servido mediante http:// el candado verde no se puede mostrar. Eso se debe a que los recursos como imágenes, JavaScript, audio, vídeo, etc., incluidos mediante http:// abren un agujero de seguridad en el sitio web seguro. Una puerta trasera a que haya problemas.

Los navegadores web sabían que esto era un problema desde hace mucho, mucho tiempo. En 1997, Internet Explorer 3.0.2 advertía a los usuarios de sitios con contenido mixto con el siguiente cuadro de diálogo.

Hoy, Google Chrome muestra un círculo con una "i" en las https:// que tengan contenido no seguro.

Y Firefox muestra un candado con un símbolo de advertencia. Que salga un candado verde en cualquiera de estos navegadores requiere que todos y cada uno de los subrecursos individuales (recursos cargados por una página) se sirvan mediante HTTPS.

Si hubieras hecho clic en "Sí" en 1997, Internet Explorer habría ignorado los peligros de contenido mixto y habría pasado a cargar subrecursos usando texto no cifrado HTTP. Hacer clic en "No" les habría impedido cargarlos, lo que a menudo habría mostrado una página rota pero segura.

Es tentador, pero ingenuo, pensar que la solución para el contenido mixto es fácil: "Simplemente carga todo con https:// y arregla tu sitio de Internet". Desgraciadamente, la plétora de contenido cargado en los sitios web modernos propios y de terceros dificulta mucho que "simplemente" se haga ese cambio.

Imagen CC BY 2.0 por Mike Mozart

En Wired documentaron su transición a https:// con una serie de entradas de blog que muestran lo difícil que puede ser cambiar todo a HTTPS. Comenzaron en abril y pasaron 5 meses en el proceso (después de haberse preparado durante meses solo para pasar a https:// su sitio web principal). En mayo escribieron acerca de un imprevisto:

«[...] uno de los mayores retos de migrar a HTTPS es preparar todo nuestro contenido para que se entregue con conexiones seguras. Si se carga una página mediante HTTPS, todos los demás activos (como imágenes y archivos Javascript) deben cargarse mediante HTTPS. Hemos visto un gran volumen de informes sobre estas cuestiones de "contenido mixto" o casos en los que un activo HTTP inseguro se carga en el contexto de una página segura, HTTPS. Para hacer nuestro despliegue correctamente, debemos asegurarnos de que tenemos pocos problemas de contenido mixto, que entregamos tanto contenido seguro de WIRED.com como sea posible".

En 2014, el New York Times identificó el contenido mixto como un gran obstáculo para ser seguros:

"Para migrar correctamente a HTTPS, todas las solicitudes de activos de página deben hacerse mediante un canal seguro. Es un desafío de enormes proporciones y hay un montón de piezas en movimiento. Debemos tener en cuenta los recursos que actualmente se están cargando desde dominios inseguros: todo desde JavaScript a activos de publicidad".

Y el W3C reconoció que esto era un gran problema diciendo: "Especialmente, la comprobación de contenido mixto tiene el potencial de dar problemas a los administradores encargados de pasar gran cantidad de contenido preexistente a HTTPS. En particular, revisar el contenido antiguo y reescribir URL de recursos manualmente es una tarea enorme". Y citó el enorme archivo de la BBC como un ejemplo complicado.

Pero no solo los sitios de medios de comunicación tienen un problema con el contenido mixto. A muchos usuarios de sistemas de gestión de contenidos les resulta difícil o imposible actualizar todos los enlaces que su sistema genera, ya que pueden estar escondidos entre archivos de configuración, código fuente o bases de datos. Además, los sitios que tienen que gestionar contenido generado por el usuario también se enfrentan a un problema con los URI (Uniform Resource Identifiers, en español, identificadores de recursos uniformes) de http://.

El contenido mixto viene con dos sabores: activo y pasivo. Los navegadores web modernos abordan los peligros de estos diferentes tipos de contenido mixto como sigue: el contenido mixto activo (el más peligroso) es automáticamente y totalmente bloqueado, el contenido mixto pasivo se permite pero aparece una advertencia.

Imagen CC BY 2.0 por Ben Tilley

El contenido activo es todo aquello que puede modificar el modelo de objetos del documento (la propia página web). Los recursos incluidos a través de las etiquetas <script>, <link>, <iframe> y <object>, los valores de CSS que utilizan url y cualquier cosa solicitada con XMLHTTPRequest pueden modificar una página, leer las cookies y acceder a las credenciales de usuario.

El contenido pasivo es lo demás: imágenes, audio, vídeo, que están escritos en la página pero que no pueden acceder a la página.

El contenido activo es una amenaza real porque si un atacante logra interceptar una solicitud de un URI de http://, puede reemplazar el contenido con el suyo. Esta no es una preocupación teórica. En 2015 Github fue atacado por un sistema denominado Great Cannon que interceptaba las solicitudes de archivos comunes de JavaScript mediante HTTP y los reemplazaba con una secuencia de comandos de ataque de JavaScript. Great Cannon convirtió en armas los equipos de usuarios inocentes interceptando el TCP (Transmission Control Protocol, en español, protocolo de control de transmisión) y explotando la vulnerabilidad inherente al contenido activo cargado desde los URI de http://.

El contenido pasivo es un tipo diferente de amenaza: debido a que las solicitudes de contenido pasivo se envían sin peligro, un espía pueden controlar las solicitudes y extraer información. Por ejemplo, un espía bien situado puede controlar las cookies, las páginas web visitadas y potencialmente la información de autenticación.

El complemento de Firefox Firesheep puede utilizarse para vigilar una red local (por ejemplo, en una cafetería) para ver las solicitudes que se envían a través de HTTP y automáticamente robar cookies, permitiendo que un usuario robe la identidad de alguien con un solo clic.

Hoy en día, los navegadores modernos bloquean el contenido activo que se carga de manera insegura, pero permiten el contenido pasivo. No obstante, la transición de todo a https:// es la única manera de solucionar todos los problemas de seguridad del contenido mixto.

Llevamos mucho tiempo queriendo ayudar a arreglar correctamente el contenido mixto y nuestro objetivo es que la web quede totalmente cifrada. Y, como otros servicios de Cloudflare, queríamos hacer de esto una experiencia de "un clic".

Imagen CC BY 2.0 por Anthony Easton

Tuvimos en cuenta diferentes enfoques:

Insertar automáticamente la actualización de solicitudes inseguras (upgrade-insecure-requests) de la directiva de la Política de seguridad de contenido

La directiva de actualización de funciones inseguras puede agregarse en un encabezado de Política de seguridad de contenido así:

Content-Security-Policy: upgrade-insecure-requests

que ordena al navegador que actualice automáticamente cualquier solicitud HTTP a HTTPS. Esto puede ser útil si el propietario del sitio web sabe que todos los subrecursos están disponibles mediante HTTPS. El sitio web no tendrá que cambiar los URI de http:// insertados en la web a https://, el navegador se encargará de ello automáticamente.

Por desgracia, hay una gran desventaja en la actualización de solicitudes inseguras. Puesto que el navegador actualiza ciegamente todos los URI a https://, independientemente de si el URI resultante funcionará realmente, las páginas pueden romperse.

Modificar todos los enlaces para que usen https://

Puesto que no todos los navegadores utilizados por los visitantes de sitios web de Cloudflare son compatibles con la actualización de solicitudes inseguras, consideramos actualizar todos los URI de http:// a https:// a medida que las páginas atraviesan nuestro servicio. Puesto que podemos analizar y modificar páginas web en tiempo real, podríamos haber creado un servicio de "actualización de solicitudes inseguras" que no dependiera del soporte del navegador.

Por desgracia, eso todavía trae el mismo problema de enlaces rotos cuando un URI de http:// se transforma en https:// pero el recurso no se puede cargar realmente usando HTTPS

Modificar enlaces que llevan a otros sitios de Cloudflare

Cloudflare ofrece a todos nuestros 4 millones de clientes Universal SSL gratis y cubrimos un gran porcentaje del tráfico web que hemos considerado simplemente actualizando de http:// a https:// los URI que sabemos que van a funcionar (porque utilizan nuestro servicio).

Esto resuelve parte del problema, pero no es una buena solución para el problema general de la actualización de HTTP a HTTPS

Crear un sistema que reescribe los URI que se sabe que funcionarán con HTTPS

Finalmente, nos decidimos a hacer algo inteligente: actualizar los URI de http:// a https:// si sabemos que pueden servirse usando HTTPS. Para averiguar qué enlaces son actualizables, recurrimos a la estupenda extensión HTTPS Everywhere de la EFF y a la listaHSTS preload de Google Chrome para aumentar nuestro conocimiento de sitios de Cloudflare que tienen SSL habilitado.

Agradecemos que la EFF haya aceptado gentilmente ayudarnos con este proyecto.

El conjunto de reglas de HTTPS Everywhere va mucho más allá de simplemente cambiar de http:// a https://. Contiene las reglas y exclusiones que le permiten (y a nosotros también) apuntar a URI específicos. Por ejemplo, esta es una regla real de HTTP Everywhere para gstatic.com:

<rule from="^http://(csi|encrypted-tbn\d|fonts|g0|[\w-]+\.metric|ssl|t\d)\.
gstatic\.com/" to="https://$1.gstatic.com/"/>

Utiliza una expresión regular para identificar subdominios específicos de gstatic.com que se pueden actualizar sin riesgos para utilizar HTTPS. El conjunto completo de reglas puede consultarse aquí.

Como tenemos que actualizar un gran número de URI insertados en páginas web (calculamos unos 5 millones por segundo) identificamos los analizadores HTML actuales y decidimos escribir uno nuevo para este tipo de tarea de reescritura. Escribiremos más acerca de su diseño, pruebas y rendimiento en una publicación futura.

Las reescrituras HTTPS automáticas ya están disponibles en el panel de control del cliente para todos los clientes de Cloudflare. Ahora, esta característica está deshabilitada por defecto y puede habilitarse con un clic:

Supervisaremos el rendimiento y la eficacia de esta función y la activaremos por defecto para los clientes de las versiones gratuita y profesional este año. También planeamos usar las funciones de la Política de seguridad de contenido para que los clientes tengan una vista automática de qué URI quedan por actualizar, a fin de que su transición a https:// sea lo más sencilla posible; a veces, solo averiguar qué URI deben cambiarse puede ser tan difícil como descubrieron en Wired.

Me encantaría que me contaras cómo te funciona esta característica.