VPN connesso ma contenuti misti ancora bloccati: cosa correggere

Metà della pagina viene renderizzata, un foglio di stile resta in grigio nel pannello Rete, e il client VPN continua a riportare un tunnel sano. Tutte e tre le osservazioni sono vere insieme, perché il browser ha giudicato una richiesta fatta dalla pagina e il tunnel non aveva voce in quel giudizio. Ciò che chiude il caso è una decisione e non un’impostazione: riparare il riferimento, escalarlo a chi possiede l’host, o abbandonare la dipendenza. Ognuna di queste opzioni ha un test poco costoso, e scegliere quella sbagliata brucia un ciclo di supporto.

Perché il tunnel non può coprire una sotto-risorsa

I contenuti misti iniziano con un documento HTTPS che richiede una sotto-risorsa in HTTP semplice. Ogni URL è giudicata secondo il proprio schema, quindi la protezione del documento padre non si estende mai a una richiesta figlia. La cifratura aggiunta sotto il browser cambia ciò che viaggia sul filo, non l’http:// richiesto dal markup.

I browser attuali dividono queste richieste in due gruppi e le trattano diversamente. Script, fogli di stile, iframe e chiamate con fetch, XMLHttpRequest o WebSocket vengono rifiutati di netto, senza alcun tentativo di aggiornamento prima. Immagini, audio e video vengono riscritti in https:// e richiesti di nuovo, e il caricamento viene abbandonato quando quel recupero sicuro fallisce. Un URL di sotto-risorsa il cui host è un indirizzo IP nudo è esente dall’aggiornamento, perciò un’immagine HTTP su un host IP resta bloccata invece di essere riparata in silenzio. La suddivisione, compresa quell’eccezione sul lato aggiornabile, è documentata nella guida di Mozilla sui contenuti misti. Chrome applica un rifiuto simile ai download non sicuri avviati da una pagina sicura, ed è per questo che un link PDF può morire mentre la pagina circostante sembra intatta.

La riga in grigio è quindi la prova che il controllo funziona, non la prova che il tunnel abbia lasciato uscire testo in chiaro. Tratta la riga come un riscontro che punta a un singolo riferimento e non all’intera pagina.

Stabilire a chi appartiene il riferimento non sicuro

Ordina l’URL incriminata in base a dove viene prodotta prima di modificare qualsiasi cosa. Quella risposta decide se puoi rilasciare una correzione oggi, se un fornitore deve pubblicarne una, o se la dipendenza deve lasciare la pagina. Leggila dalla colonna Initiatore nel pannello Rete, perché il markup sullo schermo viene spesso assemblato a runtime.

Quando l’host risponde già sulla 443 e solo il riferimento dice http, la riparazione è locale: cambia il riferimento, svuota la cache della pagina e conferma che la riga diventi https. Un host che ascolta solo sulla porta 80 non può essere messo in regola modificandolo, quindi la risorsa si sposta, viene messa dietro qualcosa che controlli tu, o se ne va. Un URL iniettato da un tag manager continua a comparire anche quando il tuo template è pulito, e quel caso appartiene a un ticket con l’URL esatta e la riga di console allegate. Dire al personale di consentire contenuti non sicuri non è una di queste opzioni, perché disattiva il controllo per ogni sito che quel profilo del browser visita.

Ripara il riferimento invece dell’impostazione del browser

Ricarica il flusso che fallisce conservando il log di rete e filtra il pannello sull’host che sospetti. La console nomina l’URL e la direttiva, il che chiarisce se una richiesta è stata rifiutata o aggiornata prima che tu tocchi un template.

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

Due controlli di supporto vale la pena conoscerli, e nessuno dei due sostituisce la riparazione. Un header Content-Security-Policy con upgrade-insecure-requests fa riscrivere al browser gli URL delle sotto-risorse http prima che lascino la pagina, il che intercetta vecchi riferimenti che non hai ancora trovato. La richiesta riscritta fallisce comunque quando l’host di destinazione non serve HTTPS, quindi l’header cambia solo quale URL il browser prova. HSTS vale per host, il che significa che una policy sul tuo dominio non fa nulla per un CDN di terze parti che non ha mai inviato l’header. Dopo una modifica al template svuota la cache della pagina e cerca nel HTML renderizzato il vecchio nome host, perché lo stesso URL può arrivare anche tramite un parziale, una stringa di traduzione o un campo del database.

Segui anche i redirect, perché una catena che parte da https:// può atterrare su una posizione http:// e il browser giudica l’ultimo salto. La -L forma del secondo comando qui sopra stampa quell’URL effettiva per te. Se l’ultimo salto è http puro, il riferimento è ancora sbagliato anche se il link che hai modificato sembrava a posto.

Confermare la pagina con la console e il pannello Rete

Ricarica con la cache disattivata e percorri di nuovo il flusso, compresi i pulsanti che caricano contenuto su richiesta. Un primo caricamento della pagina nasconde widget lazy, riquadri della mappa e script del lettore che compaiono solo dopo un clic. La console non dovrebbe contenere voci di contenuto misto e ogni riga che hai toccato dovrebbe mostrare https. Cattura la console e la riga della richiesta prima di chiudere il ticket, perché quello stato è difficile da ricostruire dopo il prossimo deploy.

Quando la risorsa appartiene a qualcun altro, invia quattro cose: l’URL esatta, il tipo di richiesta, il testo della console e la pagina in cui compare. Oscura gli identificatori di sessione in tutto ciò che incolli in un ticket. Un rapporto che dice solo che le immagini sono rotte non dà al proprietario niente da cercare.

Il tunnel continua a fare il proprio lavoro mentre la correzione vive nel riferimento che ha prodotto la richiesta. Cerca ancora una volta il nome host nel template e nel bundle del fornitore dopo il deploy, e chiudi il caso solo quando nella console non resta alcuna voce di contenuto misto bloccata.