Duono de la paĝo bildiĝas, unu stilfolio restas griza en la retpanelo, kaj la VPN-kliento daŭre raportas sanan tunelon. Ĉiuj tri observoj veras samtempe, ĉar la retumilo juĝis peton faritan de la paĝo kaj la tunelo havis neniun voĉon en tiu juĝo. Kio fermas la kazon estas decido, ne agordo: ripari la referencon, eskali ĝin al tiu, kiu posedas la gastiganton, aŭ forlasi la dependaĵon. Ĉiu el tiuj opcioj havas malmultekostan provon, kaj elekti la malĝustan konsumas subtenan ciklon.

Kial la tunelo ne povas kovri subresurson

Miksita enhavo komenciĝas per HTTPS-dokumento, kiu petas subresurson per simpla HTTP. Ĉiu URL estas juĝata laŭ sia propra skemo, do la protekto de la patra dokumento neniam etendiĝas al fila peto. Ĉifrado aldonita sub la retumilo ŝanĝas tion, kio vojaĝas sur la drato, ne la http://, kiun petis la markado.

Nuntempaj retumiloj dividas ĉi tiujn petojn en du grupojn kaj traktas ilin malsame. Skriptoj, stilfolioj, iframe-oj kaj alvokoj per fetch, XMLHttpRequest aŭ WebSocket estas tuj rifuzataj, sen ajna antaŭa ĝisdatiga provo. Bildoj, aŭdio kaj video estas reskribataj al https:// kaj denove petitaj, kaj la ŝarĝo estas forlasata kiam tiu sekura elpreno malsukcesas. URL de subresurso, kies gastiganto estas nuda IP-adreso, estas esceptita de ĝisdatigo, do HTTP-bildo ĉe IP-gastiganto restas blokita anstataŭ esti silente riparita. La divido, inkluzive tiun escepton ĉe la ĝisdatigebla flanko, estas dokumentita en la gvidilo de Mozilla pri miksita enhavo. Chrome aplikas similan rifuzon al nesekuraj elŝutoj komencitaj el sekura paĝo, kaj tial PDF-ligilo povas morti dum la ĉirkaŭa paĝo aspektas sendifekta.

La griza vico estas do la pruvo, ke la kontrolo funkcias, ne la pruvo, ke la tunelo likis klartekston. Traktu la vicon kiel trovon, kiu montras al unu sola referenco kaj ne al la tuta paĝo.

Determini, kiu posedas la nesekuran referencon

Ordigu la ofendan URL laŭ tio, kie ĝi estiĝas, antaŭ ol ŝanĝi ion ajn. Tiu respondo decidas, ĉu vi povas liveri riparon hodiaŭ, ĉu provizanto devas eldoni unu, aŭ ĉu la dependaĵo devas forlasi la paĝon. Legu ĝin en la kolumno Initiator en la retpanelo, ĉar la markado sur la ekrano ofte estas kunmetata dum plenumo.

De kie venas la URLKiu povas ripari ĝinUnua paŝo
Malprogramita en ŝablono aŭ parto, kiun vi deplojasViAnstataŭigu ĝin per la formo https:// kaj poste malplenigu la kaŝmemoron
Enĵetita de etikedadministrilo aŭ de provizanta pakaĵoLa provizanto, kun via biletoSendu la ĝustan URL, la petotipon kaj la konzolan linion
Servata nur ĉe retpordo 80 sen TLS-aŭskultantoLa posedanto de la gastigantoPetu TLS, antaŭmetu ion, kion vi kontrolas, aŭ forlasu ĝin

Kiam la gastiganto jam respondas ĉe 443 kaj nur la referenco diras http, la riparo estas loka: ŝanĝu la referencon, malplenigu la paĝan kaŝmemoron kaj konfirmu, ke la vico iĝas https. Gastiganto, kiu aŭskultas nur ĉe retpordo 80, ne povas esti konformigita per redaktado, do la resurso translokiĝas, estas antaŭmetita per io, kion vi kontrolas, aŭ foriras. URL enĵetita de etikedadministrilo daŭre aperas eĉ kiam via propra ŝablono estas pura, kaj tiu kazo apartenas al bileto kun la ĝusta URL kaj la konzola linio alkroĉitaj. Diri al la personalo, ke ili permesu nesekuran enhavon, ne estas unu el ĉi tiuj opcioj, ĉar tio malŝaltas la kontrolon por ĉiu retejo, kiun vizitas tiu retumila profilo.

Riparu la referencon anstataŭ la retumilan agordon

Reŝargu la malsukcesan fluon kun konservita retprotokolo kaj filtru la panelon laŭ la gastiganto, kiun vi suspektas. La konzolo nomas la URL kaj la direktivon, kio decidas, ĉu peto estis rifuzita aŭ ĝisdatigita, antaŭ ol vi tuŝas ŝablonon.

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

Du subtenaj kontroloj indas esti konataj, kaj neniu anstataŭas la riparon. Kapo Content-Security-Policy kun upgrade-insecure-requests igas la retumilon reskribi http-subresursajn URL-ojn antaŭ ol ili forlasas la paĝon, kio kaptas malnovajn referencojn, kiujn vi ankoraŭ ne trovis. La reskribita peto ankoraŭ malsukcesas kiam la cela gastiganto ne servas HTTPS, do la kapo nur ŝanĝas, kiun URL la retumilo provas. HSTS validas laŭ gastiganto, kio signifas, ke politiko ĉe via propra domajno faras nenion por triaranea CDN, kiu neniam sendis la kapon. Post ŝablona ŝanĝo malplenigu la paĝan kaŝmemoron kaj serĉu la malnovan gastigantan nomon en la bildigita HTML, ĉar la sama URL ankaŭ povas veni per parto, traduka ĉeno aŭ datumbaza kampo.

Sekvu ankaŭ alidirektojn, ĉar ĉeno komenciĝanta ĉe https:// povas surteriĝi ĉe http://-loko kaj la retumilo juĝas la lastan salton. La -L formo de la dua komando supre presas tiun efektivan URL por vi. Se la lasta salto estas pura http, la referenco ankoraŭ malĝustas, eĉ se la ligilo, kiun vi redaktis, aspektis en ordo.

Konfirmu la paĝon per la konzolo kaj la retpanelo

Reŝargu kun malŝaltita kaŝmemoro kaj retrairu la fluon, inkluzive la butonojn, kiuj ŝargas enhavon laŭpete. Unua paĝa ŝarĝo kaŝas mallaboremajn fenestraĵojn, mapkahelojn kaj ludilskriptojn, kiuj aperas nur post klako. La konzolo ne devus porti miksit-enhavajn enskribojn kaj ĉiu vico, kiun vi tuŝis, devus montri https. Kaptu la konzolon kaj la petan vicon antaŭ ol fermi la bileton, ĉar tiu stato estas malfacile rekonstruebla post la sekva deplojo.

Kiam la resurso apartenas al iu alia, sendu kvar aferojn: la ĝustan URL, la petotipon, la konzolan tekston kaj la paĝon, kie ĝi aperas. Kaŝu sesio-identigilojn en ĉio, kion vi algluas en bileton. Raporto, kiu nur diras, ke bildoj estas rompitaj, donas al la posedanto nenion por serĉi.

La tunelo daŭre faras sian propran laboron dum la riparo kuŝas en la referenco, kiu produktis la peton. Serĉu la gastigantan nomon ankoraŭfoje en la ŝablono kaj la provizanta pakaĵo post la deplojo, kaj fermu la kazon nur kiam neniu blokita miksit-enhava enskribo restas en la konzolo.

Rilataj artikoloj