Solucionamos el problema de contenido mixto con reescrituras HTTPS automáticas
2016-09-22
Cloudflare pretende poner fin al Internet sin cifrar. Pero la web tiene el problema del huevo y la gallina al cambiarse a HTTPS....
Seguir leyendo »
\n \n
Hoy, Google Chrome muestra un círculo con una "i" en las https:// que tengan contenido no seguro.
\nY 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.
\nSi 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.
\nEs 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.
\nImagen 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://.
\nEl 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.
\nImagen 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.
\nLlevamos 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".
\nImagen 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í:
\nContent-Security-Policy: upgrade-insecure-requests
\n 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:
\n<rule from="^http://(csi|encrypted-tbn\\d|fonts|g0|[\\w-]+\\.metric|ssl|t\\d)\\.\ngstatic\\.com/" to="https://$1.gstatic.com/"/>
\n 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.
\nLas 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:
\nSupervisaremos 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.
"],"published_at":[0,"2016-09-22T15:34:37.000+01:00"],"updated_at":[0,"2024-10-10T00:41:34.071Z"],"feature_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/77UoCKX1MDvvgaAZ9Q3PQ8/2e16989c71cdfc7e858e05ba47ad8ce6/fixing-the-mixed-content-problem-with-automatic-https-rewrites.jpg"],"tags":[1,[[0,{"id":[0,"5US4l4wdDysuDpZ4ktL3yP"],"name":[0,"HTTPS"],"slug":[0,"https"]}],[0,{"id":[0,"56P4NLXsXldfV8fsbBcmwD"],"name":[0,"Automatic HTTPS"],"slug":[0,"automatic-https"]}],[0,{"id":[0,"1HblPaFreDjetoJDJPjTAi"],"name":[0,"SSL"],"slug":[0,"ssl"]}],[0,{"id":[0,"3QI2XKrAhqhBqXR2SqDEQU"],"name":[0,"Mixed Content Errors"],"slug":[0,"mixed-content-errors"]}],[0,{"id":[0,"6QktrXeEFcl4e2dZUTZVGl"],"name":[0,"Noticias de productos"],"slug":[0,"product-news"]}],[0,{"id":[0,"6Mp7ouACN2rT3YjL1xaXJx"],"name":[0,"Seguridad"],"slug":[0,"security"]}],[0,{"id":[0,"5grQBv96AL5Ck0c8I54a0f"],"name":[0,"Crypto Week (ES)"],"slug":[0,"crypto-week"]}]]],"relatedTags":[0],"authors":[1,[[0,{"name":[0,"John Graham-Cumming"],"slug":[0,"john-graham-cumming"],"bio":[0,null],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/5vGNsXzZrtSLn2X30pnpUY/6f350e7dd36058a6422f9199b452bb02/john-graham-cumming.jpg"],"location":[0,"Lisbon, Portugal"],"website":[0,null],"twitter":[0,null],"facebook":[0,null]}]]],"meta_description":[0,null],"primary_author":[0,{}],"localeList":[0,{"name":[0,"Fixing the mixed content problem with Automatic HTTPS Rewrites Config"],"enUS":[0,"English for Locale"],"zhCN":[0,"Translated for Locale"],"zhHansCN":[0,"No Page for Locale"],"zhTW":[0,"No Page for Locale"],"frFR":[0,"Translated for Locale"],"deDE":[0,"Translated for Locale"],"itIT":[0,"No Page for Locale"],"jaJP":[0,"Translated for Locale"],"koKR":[0,"No Page for Locale"],"ptBR":[0,"No Page for Locale"],"esLA":[0,"No Page for Locale"],"esES":[0,"Translated for Locale"],"enAU":[0,"No Page for Locale"],"enCA":[0,"No Page for Locale"],"enIN":[0,"No Page for Locale"],"enGB":[0,"No Page for Locale"],"idID":[0,"No Page for Locale"],"ruRU":[0,"No Page for Locale"],"svSE":[0,"No Page for Locale"],"viVN":[0,"No Page for Locale"],"plPL":[0,"No Page for Locale"],"arAR":[0,"No Page for Locale"],"nlNL":[0,"No Page for Locale"],"thTH":[0,"No Page for Locale"],"trTR":[0,"No Page for Locale"],"heIL":[0,"No Page for Locale"],"lvLV":[0,"No Page for Locale"],"etEE":[0,"No Page for Locale"],"ltLT":[0,"No Page for Locale"]}],"url":[0,"https://blog.cloudflare.com/fixing-the-mixed-content-problem-with-automatic-https-rewrites"],"metadata":[0,{"title":[0],"description":[0],"imgPreview":[0,""]}]}],"locale":[0,"es-es"],"translations":[0,{"posts.by":[0,"De:"],"footer.gdpr":[0,"RGPD"],"lang_blurb1":[0,"Esta publicación también está disponible en {lang1}."],"lang_blurb2":[0,"Esta publicación también está disponible en {lang1} y {lang2}."],"lang_blurb3":[0,"Esta publicación también está disponible en {lang1}, {lang2} y {lang3}."],"footer.press":[0,"Prensa"],"header.title":[0,"Blog de Cloudflare"],"search.clear":[0,"Borrar"],"search.filter":[0,"Filtrar"],"search.source":[0,"Fuente"],"footer.careers":[0,"Empleo"],"footer.company":[0,"Empresa"],"footer.support":[0,"Asistencia"],"footer.the_net":[0,"theNET"],"search.filters":[0,"Filtros"],"footer.our_team":[0,"Nuestro equipo"],"footer.webinars":[0,"Seminarios web"],"page.more_posts":[0,"Más publicaciones"],"posts.time_read":[0,"{time} min de lectura"],"search.language":[0,"Idioma"],"footer.community":[0,"Comunidad"],"footer.resources":[0,"Recursos"],"footer.solutions":[0,"Soluciones"],"footer.trademark":[0,"Marca"],"header.subscribe":[0,"Suscribirse"],"footer.compliance":[0,"Conformidad"],"footer.free_plans":[0,"Planes gratuitos"],"footer.impact_ESG":[0,"Impact/ESG"],"posts.follow_on_X":[0,"Síguenos en X"],"footer.help_center":[0,"Centro de ayuda"],"footer.network_map":[0,"Mapa de red"],"header.please_wait":[0,"Un momento..."],"page.related_posts":[0,"Publicaciones relacionadas"],"search.result_stat":[0,"Resultados {search_range} de {search_total} para {search_keyword}"],"footer.case_studies":[0,"Casos prácticos"],"footer.connect_2024":[0,"Connect 2024"],"footer.terms_of_use":[0,"Condiciones de uso"],"footer.white_papers":[0,"Notas técnicas"],"footer.cloudflare_tv":[0,"Cloudflare TV"],"footer.community_hub":[0,"Foro de comunidad"],"footer.compare_plans":[0,"Comparar planes"],"footer.contact_sales":[0,"Comunícate con el departamento de ventas"],"header.contact_sales":[0,"Comunícate con el departamento de ventas"],"header.email_address":[0,"Dirección de correo electrónico"],"page.error.not_found":[0,"Página no encontrada"],"footer.developer_docs":[0,"Documentación para desarrolladores"],"footer.privacy_policy":[0,"Política de privacidad"],"footer.request_a_demo":[0,"Solicita una demostración"],"page.continue_reading":[0,"Seguir leyendo"],"footer.analysts_report":[0,"Informes de analistas"],"footer.for_enterprises":[0,"Para empresas"],"footer.getting_started":[0,"Primeros pasos"],"footer.learning_center":[0,"Centro de aprendizaje"],"footer.project_galileo":[0,"Proyecto Galileo"],"pagination.newer_posts":[0,"Publicaciones más recientes"],"pagination.older_posts":[0,"Publicaciones anteriores"],"posts.social_buttons.x":[0,"Comenta en X"],"search.icon_aria_label":[0,"Buscar"],"search.source_location":[0,"Origen/Ubicación"],"footer.about_cloudflare":[0,"Acerca de Cloudflare"],"footer.athenian_project":[0,"Proyecto Athenian"],"footer.become_a_partner":[0,"Ser socio"],"footer.cloudflare_radar":[0,"Cloudflare Radar"],"footer.network_services":[0,"Servicios de red"],"footer.trust_and_safety":[0,"Confianza y seguridad"],"header.get_started_free":[0,"Empieza ya de forma gratuita"],"page.search.placeholder":[0,"Buscar en Cloudflare"],"footer.cloudflare_status":[0,"Estado de Cloudflare"],"footer.cookie_preference":[0,"Preferencias de cookies"],"header.valid_email_error":[0,"Debe ser un correo electrónico válido."],"search.result_stat_empty":[0,"Resultados {search_range} de {search_total}"],"footer.connectivity_cloud":[0,"Conectividad cloud"],"footer.developer_services":[0,"Servicios para desarrolladores"],"footer.investor_relations":[0,"Relaciones con inversores"],"page.not_found.error_code":[0,"Código de error: 404"],"search.autocomplete_title":[0,"Inserta una consulta. Pulsa Intro para enviarla."],"footer.logos_and_press_kit":[0,"Logotipos y dossier de prensa"],"footer.application_services":[0,"Servicios para aplicaciones"],"footer.get_a_recommendation":[0,"Sugerencias"],"posts.social_buttons.reddit":[0,"Comenta en Reddit"],"footer.sse_and_sase_services":[0,"Servicios SSE y SASE"],"page.not_found.outdated_link":[0,"Puede que tengas un enlace obsoleto o que hayas escrito la dirección incorrectamente."],"footer.report_security_issues":[0,"Informar sobre problemas de seguridad"],"page.error.error_message_page":[0,"Lamentablemente, no podemos encontrar la página que buscas."],"header.subscribe_notifications":[0,"Suscríbete para recibir notificaciones de nuevas publicaciones:"],"footer.cloudflare_for_campaigns":[0,"Cloudflare for Campaigns"],"header.subscription_confimation":[0,"Suscripción confirmada. ¡Gracias por suscribirte!"],"posts.social_buttons.hackernews":[0,"Debatir en Hacker News"],"footer.diversity_equity_inclusion":[0,"Diversidad, equidad e inclusión"],"footer.critical_infrastructure_defense_project":[0,"Proyecto de protección de infraestructuras críticas"]}]}" ssr="" client="load" opts="{"name":"PostCard","value":true}" await-children="">2016-09-22
Cloudflare pretende poner fin al Internet sin cifrar. Pero la web tiene el problema del huevo y la gallina al cambiarse a HTTPS....
Seguir leyendo »