VPN conectado pero o contido mixto segue bloqueado: que cómpre corrixir

A metade da páxina represéntase, unha folla de estilos queda en gris no panel Rede, e o cliente VPN segue informando dun túnel san. As tres observacións son certas ao mesmo tempo, porque o navegador xulgou unha solicitude que fixo a páxina e o túnel non tiña voto nese xuízo. O que pecha o caso é unha decisión e non un axuste: reparar a referencia, escalala a quen posúe o servidor, ou abandonar a dependencia. Cada unha desas opcións ten unha proba barata, e escoller a errada consome un ciclo de soporte.

Por que o túnel non pode cubrir un subrecurso

O contido mixto comeza cun documento HTTPS que pide un subrecurso por HTTP simple. Cada URL xúlgase polo seu propio esquema, así que a protección do documento pai nunca se estende a unha solicitude filla. O cifrado engadido por debaixo do navegador cambia o que viaxa polo cable, non o http:// que pediu a marcação.

Os navegadores actuais clasifican estas solicitudes en dous grupos e trátanas de xeito distinto. Os scripts, as follas de estilos, os iframes e as chamadas con fetch, XMLHttpRequest ou WebSocket rexéitanse de plano, sen intento previo de actualización. As imaxes, o audio e o vídeo reescríbense a https:// e vólvense pedir, e a carga abandónase cando falla esa obtención segura. Un URL de subrecurso cuxo servidor é un enderezo IP espido queda exento da actualización, así que unha imaxe HTTP nun servidor IP segue bloqueada en lugar de repararse en silencio. A división, incluída esa excepción no lado actualizable, está documentada na guía de Mozilla sobre contido mixto. Chrome aplica un rexeitamento semellante ás descargas non seguras iniciadas desde unha páxina segura, e por iso unha ligazón PDF pode morrer mentres a páxina que a rodea parece intacta.

A fila en gris é, polo tanto, a proba de que o control funciona, non a proba de que o túnel deixase escapar texto en claro. Trata a fila como un achado que apunta a unha soa referencia e non á páxina enteira.

Decidir a quen pertence a referencia non segura

Ordena o URL infractor segundo onde se produce antes de tocar nada. Esa resposta decide se podes publicar unha corrección hoxe, se un provedor ten que publicar unha, ou se a dependencia debe saír da páxina. Lélea na columna Iniciador do panel Rede, porque a marcação na pantalla adoita montarse en tempo de execución.

Cando o servidor xa responde no 443 e só a referencia di http, a reparación é local: cambia a referencia, baleira a caché da páxina e confirma que a fila pasa a https. Un servidor que só escoita no porto 80 non se pode poñer en regra editándoo, así que o recurso múdase, ponse detrás de algo que controles, ou desaparece. Un URL inxectado por un xestor de etiquetas segue aparecendo aínda que o teu propio modelo estea limpo, e ese caso pertence a un tícket co URL exacto e a liña da consola adxuntos. Dicirlle ao persoal que permita contido non seguro non é ningunha destas opcións, porque desactiva a comprobación para cada sitio que visita ese perfil de navegador.

Reparar a referencia en lugar do axuste do navegador

Recarga o fluxo que falla conservando o rexistro de rede e filtra o panel polo servidor que sospeitas. A consola nomea o URL e a directiva, o que resolve se unha solicitude foi rexeitada ou actualizada antes de que toques un modelo.

curl -sSI https://cdn.example.org/vendor.js | head -n 1
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' -L https://cdn.example.org/vendor.js

Dous controis de apoio paga a pena coñecelos, e ningún substitúe a reparación. Unha cabeceira Content-Security-Policy con upgrade-insecure-requests fai que o navegador reescriba os URL de subrecurso http antes de que saian da páxina, o que atrapa referencias antigas que aínda non atopaches. A solicitude reescrita segue fallando cando o servidor de destino non serve HTTPS, así que a cabeceira só cambia que URL tenta o navegador. HSTS aplícase por servidor, o que significa que unha política no teu propio dominio non fai nada por un CDN de terceiros que nunca enviou a cabeceira. Despois dun cambio de modelo baleira a caché da páxina e busca o nome de servidor antigo no HTML renderizado, porque o mesmo URL tamén pode chegar por un parcial, unha cadea de tradución ou un campo da base de datos.

Segue tamén os redireccionamentos, porque unha cadea que comeza en https:// pode aterrar nunha localización http:// e o navegador xulga o último salto. A -L forma do segundo comando de arriba imprime ese URL efectivo por ti. Se o último salto é http puro, a referencia segue mal aínda que a ligazón que editaches parecese correcta.

Confirmar a páxina coa consola e o panel Rede

Recarga coa caché desactivada e percorre o fluxo outra vez, incluídos os botóns que cargan contido a demanda. Unha primeira carga de páxina agocha widgets preguiceiros, teselas de mapa e scripts de reprodutor que só aparecen tras un clic. A consola non debería conter entradas de contido mixto e cada fila que tocases debería mostrar https. Captura a consola e a fila de solicitude antes de pechar o tícket, porque ese estado é difícil de reconstruír tras o despregamento seguinte.

Cando o recurso é doutra persoa, envía catro cousas: o URL exacto, o tipo de solicitude, o texto da consola e a páxina onde aparece. Oculta os identificadores de sesión en todo o que pegues nun tícket. Un informe que só di que as imaxes están rotas non lle dá nada que buscar ao dono.

O túnel segue facendo o seu propio traballo mentres a corrección vive na referencia que produciu a solicitude. Busca unha vez máis o nome de servidor no modelo e no paquete do provedor tras o despregamento, e pecha o caso só cando non quede ningunha entrada de contido mixto bloqueada na consola.