VPN ligado mas conteúdo misto ainda bloqueado: o que corrigir

Metade da página é renderizada, uma folha de estilos fica cinzenta no painel Rede, e o cliente VPN continua a reportar um túnel saudável. As três observações são verdadeiras ao mesmo tempo, porque o navegador julgou um pedido que a página fez e o túnel não tinha voto nesse julgamento. O que fecha o caso é uma decisão e não um ajuste: reparar a referência, escalá-la para quem é dono do anfitrião, ou abandonar a dependência. Cada uma dessas opções tem um teste barato, e escolher a errada consome um ciclo de suporte.

Porque é que o túnel não consegue cobrir um subrecurso

O conteúdo misto começa com um documento HTTPS que pede um subrecurso por HTTP simples. Cada URL é julgada pelo seu próprio esquema, pelo que a proteção do documento pai nunca se estende a um pedido filho. A encriptação acrescentada abaixo do navegador muda o que viaja no fio, não o http:// que a marcação pediu.

Os navegadores atuais dividem estes pedidos em dois grupos e tratam-nos de forma diferente. Scripts, folhas de estilos, iframes e chamadas com fetch, XMLHttpRequest ou WebSocket são recusados de imediato, sem qualquer tentativa de atualização prévia. Imagens, áudio e vídeo são reescritos para https:// e pedidos de novo, e o carregamento é abandonado quando essa obtenção segura falha. Um URL de subrecurso cujo anfitrião é um endereço IP puro está isento da atualização, pelo que uma imagem HTTP num anfitrião IP continua bloqueada em vez de ser reparada em silêncio. A divisão, incluindo essa exceção do lado atualizável, está documentada no guia da Mozilla sobre conteúdo misto. O Chrome aplica uma recusa semelhante a transferências não seguras iniciadas a partir de uma página segura, e é por isso que uma ligação PDF pode morrer enquanto a página em volta parece intacta.

A linha cinzenta é, portanto, a prova de que o controlo funciona, não a prova de que o túnel deixou escapar texto simples. Trate a linha como um achado que aponta para uma única referência e não para a página inteira.

Decidir a quem pertence a referência não segura

Ordene o URL infrator pelo local onde é produzido antes de alterar seja o que for. Essa resposta decide se pode publicar uma correção hoje, se um fornecedor tem de publicar uma, ou se a dependência tem de sair da página. Leia-a na coluna Iniciador do painel Rede, porque a marcação no ecrã é muitas vezes montada em tempo de execução.

Quando o anfitrião já responde na 443 e só a referência diz http, a reparação é local: altere a referência, limpe a cache da página e confirme que a linha passa a https. Um anfitrião que só escuta na porta 80 não pode ser posto em conformidade por edição, pelo que o recurso muda de sítio, fica atrás de algo que controla, ou desaparece. Um URL injetado por um gestor de etiquetas continua a aparecer mesmo quando o seu modelo está limpo, e esse caso pertence a um ticket com o URL exato e a linha da consola anexados. Dizer ao pessoal para permitir conteúdo não seguro não é nenhuma destas opções, porque desliga a verificação para todos os sítios que esse perfil de navegador visita.

Reparar a referência em vez do ajuste do navegador

Recarregue o fluxo que falha com o registo de rede preservado e filtre o painel pelo anfitrião que suspeita. A consola indica o URL e a diretiva, o que resolve se um pedido foi recusado ou atualizado antes de tocar num 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

Dois controlos de apoio vale a pena conhecer, e nenhum substitui a reparação. Um cabeçalho Content-Security-Policy com upgrade-insecure-requests faz o navegador reescrever os URL de subrecurso http antes de saírem da página, o que apanha referências antigas que ainda não encontrou. O pedido reescrito continua a falhar quando o anfitrião de destino não serve HTTPS, pelo que o cabeçalho só muda o URL que o navegador tenta. O HSTS aplica-se por anfitrião, o que significa que uma política no seu próprio domínio não faz nada por um CDN de terceiros que nunca enviou o cabeçalho. Depois de uma alteração ao modelo, limpe a cache da página e procure o nome de anfitrião antigo no HTML renderizado, porque o mesmo URL também pode chegar por um parcial, uma cadeia de tradução ou um campo da base de dados.

Siga também os redirecionamentos, porque uma cadeia que começa em https:// pode aterrar num local http:// e o navegador julga o último salto. A -L forma do segundo comando acima imprime esse URL efetivo por si. Se o último salto for http puro, a referência continua errada mesmo que a ligação que editou parecesse bem.

Confirmar a página com a consola e o painel Rede

Recarregue com a cache desativada e percorra o fluxo outra vez, incluindo os botões que carregam conteúdo a pedido. Um primeiro carregamento da página esconde widgets preguiçosos, mosaicos de mapa e scripts de leitor que só aparecem depois de um clique. A consola não deve conter entradas de conteúdo misto e cada linha que tocou deve mostrar https. Capture a consola e a linha do pedido antes de fechar o ticket, porque esse estado é difícil de reconstruir após a implementação seguinte.

Quando o recurso pertence a outra pessoa, envie quatro coisas: o URL exato, o tipo de pedido, o texto da consola e a página onde aparece. Oculte os identificadores de sessão em tudo o que colar num ticket. Um relatório que só diz que as imagens estão quebradas não dá nada ao dono para procurar.

O túnel continua a fazer o seu próprio trabalho enquanto a correção vive na referência que produziu o pedido. Procure o nome de anfitrião mais uma vez no modelo e no pacote do fornecedor após a implementação, e feche o caso só quando não restar nenhuma entrada de conteúdo misto bloqueada na consola.