Kiel fari HTTPS la unua peto per VPN

Retumilo, kiu unue tajpas http:// kaj alteriĝas sur https:// post kiam alidirektilo jam sendis unu peton klare, kaj VPN ne ŝanĝas tion. La tunelo protektas la kruron de la kliento ĝis la elirnodo; ĝi ĉifras nenion super la transporttavolo, do observanto inter la eliro kaj la origino ankoraŭ vidas la klartekston salteti. Fari HTTPS la unua peto estas klientflanka ŝanĝo kun tri partoj: vera HTTPS-adreso, la ĝisdatiga reĝimo de la retumilo kaj la propra politiko de la retejo. La subaj paŝoj estas la ordo, kiun mi uzas, ĉiu kun la ĉeko, kiu diras al vi, ĉu ĝi bezonis.

Paŝo 1: konfirmu kio efektive estas la unua peto

Antaŭ ol ŝanĝi ion ajn, rigardu kion sendas la retumilo. Malfermu la retan panelon kun la paĝo reŝargita el malvarma kaŝmemoro kaj legu la unuan vicon: se la skemo estas http kaj la stato estas 301 aŭ 308, ĉio post tiu vico estas dua peto. curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com reproduktas la saman sekvencon ekster la retumilo kaj presas la URL, kiun vi alvenis.

Du rezultoj estas eblaj kaj ili bezonas malsamajn korektojn. Se la retejo servas HTTPS sur la sama gastiganto, la solvo estas ĉesi publikigi la HTTP-formon: ĝisdatigi la legosignon, la vikian ligilon, la labortablan ŝparvojon kaj la retpoŝtan ŝablonon alklaku. Se la retejo tute ne servas HTTPS, neniu retumila agordo kreos ĝin, kaj la honesta respondo estas, ke la celo estas la problemo. Ne paperu la duan kazon kun escepto, ĉar atestilescepto sur kontopaĝo konvertas transportproblemon en akreditan problemon. Skribu en kiu kazo vi troviĝas antaŭ ol vi tuŝas agordon.

Paŝo 2: ŝaltu la reĝimon nur HTTPS de la retumilo

La ĝisdatiga reĝimo estas la dua parto, kaj la reĝimoj ne estas interŝanĝeblaj. Kontrolu kion la via faras antaŭ ol vi ebligas ĝin: ĝisdatigi silente, ĝisdatigi kun averto aŭ rifuzi ŝargi.

En Fajrovulpo la kontroloj vivas malantaŭ about:config kaj en la paĝo pri privateca agordo, kun dom.security.https_only_mode kiel la ŝaltilo kaj po-retejaj esceptoj administritaj el la pendserurmenuo. En Chrome kaj Edge la sama ideo troviĝas sub Agordoj, Privateco kaj sekureco, Sekureco, etikeditaj Ĉiam uzu sekurajn konektojn. Kia ajn estas la etikedo, kontrolu la konduton kontraŭ gastiganto, kiu respondas nur sur la haveno 80, ĉar reĝimo kiu ĝisdatigas kaj poste silente falas ne estas la protekto, kiun vi pensas, ke vi ebligis. La Firefox-Nur HTTPS-dokumentado priskribas la ĝisdatigon, averton kaj esceptan konduton por tiu retumilo.

Paŝo 3: riparu la rimedojn, ne nur la adresbreton

Kiam ĝisdatigo malsukcesas, legu la precizan eraron anstataŭ la adresbreton. Gastiganto sen HTTPS-aŭskultanto, gastiga nomo kiu ne kongruas kun la atestilo kaj eksvalidiĝinta ĉeno produktas malsamajn mesaĝojn kaj apartenas al malsamaj posedantoj. Nur la unua estas servilflanka breĉo; la dua estas kutime legosigno kiu neniam estis ĝisdatigita; la tria estas renoviga problemo, al kiu la VPN-konekto estas negrava.

Ne aldonu atestil-escepton al konta retejo ĉar la VPN estas ŝaltita. La escepto malŝaltas la kontrolon, kiu kaptintus ĝuste la interkapton, kiun VPN intencas malhelpi.

La tria parto estas ene de la paĝo, kaj ĝi estas tiu, kiun homoj mankas. Paĝo, kiu ŝarĝas per HTTPS, ankoraŭ povas tiri bildojn, tiparojn aŭ skriptojn de http-URL, kaj la retumilo aŭ blokos ilin aŭ malaltigos la sekurecan indikilon por la tuta paĝo. Inspektu la malsukcesajn petojn en la reto-panelo kaj riparu la rimedreferencojn ĉe ilia posedanto prefere ol supozi, ke la adresbreto priskribas ĉiun peton. En retejo, kiun vi kuras, tio signifas korekti la konservitajn URL-ojn en la CMS aŭ la ŝablonon anstataŭ reverki ilin en la retumilo. Se vi ne povas ŝanĝi la fonton, registru la miksitan enhavon kiel konatan breĉon, ĉar pendseruro super paĝo, kiu tiras klartekstojn, estas falsa signalo.

Paŝo 4: kion HSTS aldonas, kaj kion ĝi ne

HSTS estas reteja politiko prefere ol retumila prefero, kaj ĝi estas la sola mekanismo ĉi tie, kiu postvivas tajpitan http:// sur nova profilo. Post kiam retumilo vidis Strict-Transport-Security kaplinion por gastiganto, ĝi reverkas postajn petojn al https antaŭ sendi ilin, kio estas ĝuste la posedaĵo, kiun vi volas. Ĝi faras nenion por gastiganto kiun la retumilo neniam vizitis, kaj nenion por malsama gastiga nomo kiu servas la saman aplikaĵon.

Kontrolu, kion sendas la origino per curl -sSI https://example.com | grep -i strict-transport-security. Mankas kaplinio estas servila ŝanĝo kaj ne io, kion kliento povas instali. Se ĝi ĉeestas, legu max-age kaj ĉu includeSubDomains estas agordita, ĉar mallonga maksimuma aĝo eksvalidiĝas inter vizitoj kaj mankanta includeSubDomains lasas ĉiun subdomajnon neprotektita. RFC 6797 difinas kiel uzanta agento aplikas la politikon kaj kion ĝi povas ignori. Antaŭŝarĝo estas aparta devontigo, do kontrolu staton per la hstspreload.org API antaŭ ol promesi al iu ajn, ke domajno estas en la listo.

Konfirmo kaj retroigo

Revuo estas malmultekosta por la klientaj agordoj kaj multekosta por HSTS. Malŝalti HTTPS-nur-reĝimon tuj restarigas la antaŭan konduton; longa max-aĝo ne faras, kaj vizitantoj, kiuj jam ricevis ĝin, daŭre ĝisdatigas ĝis ĝi eksvalidiĝas.

Do kontrolu en ordo antaŭ ol voki ĝin farita. Reŝargi el malvarma kaŝmemoro kaj konfirmu, ke la unua peto en la reto-panelo estas https sen antaŭa alidirekto. Tiam kontrolu subdomajnon, ĉar includeSubDomains estas kie ĉi tiuj politikoj kutime rezultas pli mallarĝaj ol supozite. Tiam kontrolu unu paĝon, kiu tiras triajn aktivaĵojn, ĉar miksita enhavo estas la fiasko, kiu postvivas ĉiun alian solvon.

Se la unua peto ankoraŭ estas http post ĉio, la kliento ne plu estas la variablo: la ligilo kiun homoj alklakas estas. Serĉu la lokojn, kiujn vi kontrolas, por la http-formo de la gastiga nomo, ĝisdatigu ilin kaj reprovi per la sama malvarma kaŝmemoro reŝargi. Tenu la VPN-demandon aparta ĉie, ĉar la tunelo ŝanĝas kiu povas vidi la peton kaj neniam ŝanĝas ĉu la peto estas ĉifrita. La linio por enmeti la bileton estas, ke la unua peto estas tiu grava, kaj alidirektilo estas nur kvitanco por jam sendita peto.