Si ta bëni HTTPS kërkesën e parë përmes një VPN

Një shfletues që shtyp fillimisht http:// dhe zbret në https:// pas një ridrejtimi, ka dërguar tashmë një kërkesë të qartë dhe një VPN nuk e ndryshon këtë. Tuneli mbron këmbën nga klienti në nyjen e daljes; ai nuk kodon asgjë mbi shtresën e transportit, kështu që një vëzhgues midis daljes dhe origjinës ende sheh hop-in e tekstit të thjeshtë. Bërja e HTTPS-së si kërkesa e parë është një ndryshim nga ana e klientit me tre pjesë: një adresë reale HTTPS, modaliteti i përmirësimit të shfletuesit dhe politika e vetë sajtit. Hapat e mëposhtëm janë renditja që përdor, secili me kontrollin që ju tregon nëse u desh.

Hapi 1: konfirmoni se cila është në të vërtetë kërkesa e parë

Para se të ndryshoni ndonjë gjë, shikoni se çfarë dërgon shfletuesi. Hapni panelin e rrjetit me faqen e ringarkuar nga një memorie e ftohtë dhe lexoni rreshtin e parë: nëse skema është http dhe statusi është 301 ose 308, gjithçka pas atij rreshti është një kërkesë e dytë. curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com riprodhon të njëjtën sekuencë jashtë shfletuesit dhe printon URL-në ku përfunduat.

Dy rezultate janë të mundshme dhe kanë nevojë për rregullime të ndryshme. Nëse sajti shërben HTTPS në të njëjtin host, zgjidhja është ndalimi i publikimit të formularit HTTP: përditësoni faqeshënuesin, lidhjen wiki, shkurtoren e desktopit dhe shabllonin e emailit që njerëzit klikojnë. Nëse faqja nuk shërben fare HTTPS, asnjë cilësim i shfletuesit nuk do ta krijojë atë dhe përgjigjja e sinqertë është se problemi është destinacioni. Mos e shkruani rastin e dytë me përjashtim, sepse një përjashtim i certifikatës në një faqe llogarie konverton një problem transporti në një problem kredenciali. Shkruani se në cilin rast jeni përpara se të prekni një cilësim.

Hapi 2: aktivizoni modalitetin vetëm HTTPS të shfletuesit

Modaliteti i përmirësimit është pjesa e dytë dhe mënyrat nuk janë të këmbyeshme. Kontrolloni se çfarë bën juaji përpara se ta aktivizoni: përditësoje në heshtje, përditëso me një paralajmërim ose refuzo ngarkimin.

Në Firefox kontrollet qëndrojnë prapa about:config dhe në faqen e cilësimeve të privatësisë, me dom.security.https_only_mode si çelës dhe përjashtimet për faqe të menaxhuara nga menyja e drynit. Në Chrome dhe Edge, e njëjta ide qëndron te Cilësimet, Privatësia dhe siguria, Siguria, etiketuar Përdor gjithmonë lidhje të sigurta. Sido që të jetë etiketa, verifikoni sjelljen ndaj një hosti që përgjigjet vetëm në portin 80, sepse një modalitet që përmirësohet dhe më pas bie në heshtje nuk është mbrojtja që mendoni se keni aktivizuar. Dokumentacioni "Vetëm HTTPS-Firefox" përshkruan përmirësimin, paralajmërimin dhe sjelljen e përjashtimit për atë shfletues.

Hapi 3: rregulloni burimet, jo vetëm shiritin e adresave

Kur një përmirësim dështon, lexoni gabimin e saktë në vend të shiritit të adresës. Një host pa dëgjues HTTPS, një emër pritës që nuk përputhet me certifikatën dhe një zinxhir i skaduar prodhojnë mesazhe të ndryshme dhe u përkasin pronarëve të ndryshëm. Vetëm e para është një boshllëk nga ana e serverit; i dyti është zakonisht një faqerojtës që nuk është përditësuar kurrë; i treti është një problem rinovimi për të cilin lidhja VPN është e parëndësishme.

Mos shtoni një përjashtim certifikate në një sajt llogarie sepse VPN është aktiv. Përjashtimi çaktivizon kontrollin që do të kishte kapur pikërisht përgjimin që një VPN synon të parandalojë.

Pjesa e tretë është brenda faqes dhe është ajo që njerëzve u mungon. Një faqe që ngarkon përmes HTTPS mund të tërheqë ende imazhe, fonte ose skripte nga një URL http dhe shfletuesi ose do t'i bllokojë ato ose do të ulë treguesin e sigurisë për të gjithë faqen. Inspektoni kërkesat e dështuara në panelin e rrjetit dhe rregulloni referencat e burimeve tek pronari i tyre në vend që të supozoni se shiriti i adresave përshkruan çdo kërkesë. Në një sajt që drejtoni, kjo do të thotë të korrigjoni URL-të e ruajtura në CMS ose shabllonin në vend që t'i rishkruani ato në shfletues. Nëse nuk mund ta ndryshoni burimin, regjistrojeni përmbajtjen e përzier si një boshllëk të njohur, sepse një dry mbi një faqe që tërheq burime teksti të thjeshtë është një sinjal i rremë.

Hapi 4: çfarë shton HSTS dhe çfarë jo

HSTS është një politikë sajti dhe jo një preferencë e shfletuesit dhe është i vetmi mekanizëm këtu që i mbijeton një http:// të shtypur në një profil të ri. Pasi një shfletues të ketë parë një kokë Strict-Transport-Security për një host, ai rishkruan kërkesat e mëvonshme në https përpara se t'i dërgojë ato, që është pikërisht vetia që dëshironi. Nuk bën asgjë për një host që shfletuesi nuk e ka vizituar kurrë dhe asgjë për një emër tjetër pritës që shërben të njëjtin aplikacion.

Kontrollo se çfarë dërgon origjina me curl -sSI https://example.com | grep -i strict-transport-security. Një kokë që mungon është një ndryshim i serverit dhe jo diçka që një klient mund të instalojë. Nëse është i pranishëm, lexoni max-age dhe nëse includeSubDomains është caktuar, sepse një moshë maksimale e shkurtër skadon ndërmjet vizitave dhe një includeSubDomains që mungon e lë çdo nëndomain të pambrojtur. RFC 6797 përcakton se si një agjent përdoruesi e zbaton politikën dhe çfarë mund të injorojë. Parangarkimi është një angazhim më vete, prandaj kontrolloni statusin përmes API-së hstspreload.org përpara se t'i premtoni dikujt që një domen është në listë.

Verifikimi dhe rikthimi

Rivendosja është e lirë për cilësimet e klientit dhe e shtrenjtë për HSTS. Çaktivizimi i modalitetit vetëm HTTPS rikthen menjëherë sjelljen e mëparshme; mosha maksimale e gjatë jo, dhe vizitorët që e kanë marrë tashmë vazhdojnë ta përmirësojnë derisa të skadojë.

Kështu që verifikojeni me radhë përpara se ta kryeni atë. Ringarko nga një memorie e ftohtë dhe konfirmo që kërkesa e parë në panelin e rrjetit është https pa ridrejtim të mëparshëm. Pastaj kontrolloni një nëndomain, sepse përfshirja e nënDomainëve është vendi ku këto politika zakonisht rezultojnë të jenë më të ngushta se sa supozohej. Më pas kontrolloni një faqe që tërheq asete të palëve të treta, pasi përmbajtja e përzier është dështimi që i mbijeton çdo rregullimi tjetër.

Nëse kërkesa e parë është ende http pas gjithë kësaj, klienti nuk është më ndryshorja: lidhja që njerëzit klikojnë është. Kërkoni vendet që kontrolloni për formën http të emrit të hostit, përditësoni ato dhe ri-testoni me të njëjtin ringarkim të memories së ftohtë. Mbajeni pyetjen VPN të ndarë gjatë gjithë kohës, sepse tuneli ndryshon kush mund ta shohë kërkesën dhe nuk ndryshon kurrë nëse kërkesa është e koduar. Rreshti për të vendosur në biletë është se kërkesa e parë është ajo që ka rëndësi, dhe një ridrejtim është vetëm një faturë për një kërkesë të dërguar tashmë.