Kuidas muuta HTTPS VPN-i kaudu esimeseks päringuks

Brauser, mis tippib esmalt http:// ja jõuab pärast ümbersuunamist aadressile https:// ja VPN seda ei muuda. Tunnel kaitseb jalga kliendist väljumissõlmeni; see ei krüpteeri midagi transpordikihi kohal, nii et väljumise ja lähtepunkti vahel olev vaatleja näeb ikkagi tavateksti hüpet. HTTPS-i muutmine esimeseks päringuks on kliendipoolne muudatus, mis koosneb kolmest osast: tegelik HTTPS-aadress, brauseri täiendusrežiim ja saidi enda poliitika. Allolevad toimingud on minu kasutatavas järjekorras, igaühel on tšekk, mis annab teada, kas kulus.

1. samm: kinnitage, mis esimene päring tegelikult on

Enne millegi muutmist vaadake, mida brauser saadab. Avage võrgupaneel külmast vahemälust uuesti laaditud lehega ja lugege esimest rida: kui skeem on http ja olek on 301 või 308, on kõik pärast seda rida teine päring. curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com taasesitab sama jada väljaspool brauserit ja prindib URL-i, kuhu sattusite.

Võimalik on kaks tulemust ja need vajavad erinevaid parandusi. Kui sait teenindab HTTPS-i samas hostis, tuleb lahendus peatada HTTP-vormi avaldamine: värskendage järjehoidjat, wiki linki, töölaua otseteed ja meilimalli, mida inimesed klõpsavad. Kui sait HTTPS-i üldse ei teeninda, ei loo seda ükski brauseri seade ja aus vastus on, et probleem on sihtkohas. Ärge kirjutage paberile teist juhtumit erandiga, sest kontolehel olev sertifikaadi erand muudab transpordiprobleemi mandaadiprobleemiks. Enne seade puudutamist kirjutage üles, millises juhtumis te olete.

2. toiming: lülitage brauseris sisse ainult HTTPS-i režiim

Täiendusrežiim on teine osa ja režiimid ei ole omavahel asendatavad. Enne lubamist kontrollige, mida teie oma teeb: vaikselt täiendada, hoiatusega täiendada või laadimisest keelduda.

Firefoxis asuvad juhtnupud about:config taga ja privaatsusseadete lehel, lüliti dom.security.https_only_mode ja tabaluku menüüst hallatavad saidipõhised erandid. Chrome'is ja Edge'is on sama idee jaotises Seaded, Privaatsus ja turvalisus, Turvalisus, sildiga Kasuta alati turvalisi ühendusi. Olenemata sildist, kontrollige käitumist hosti suhtes, mis vastab ainult pordile 80, sest režiim, mis uueneb ja seejärel vaikselt tagasi langeb, ei ole teie arvates see kaitse, mille olete lubanud. Ainult Firefoxi HTTPS-i dokumentatsioon kirjeldab selle brauseri versiooniuuendusi, hoiatusi ja erandeid.

3. samm: parandage ressursse, mitte ainult aadressiriba

Kui täiendamine ebaõnnestub, lugege aadressiriba asemel täpset viga. Host, millel pole HTTPS-kuulajat, sertifikaadile mittevastav hostinimi ja aegunud kett toodavad erinevaid sõnumeid ja kuuluvad erinevatele omanikele. Ainult esimene on serveripoolne lünk; teine on tavaliselt järjehoidja, mida pole kunagi värskendatud; kolmas on uuendamisprobleem, mille puhul VPN-ühendus ei ole oluline.

Ärge lisage konto saidile sertifikaadi erandit, kuna VPN on sisse lülitatud. Erand keelab kontrolli, mis oleks tabanud täpselt pealtkuulamise, mida VPN on mõeldud takistama.

Kolmas osa on lehe sees ja see on see, millest inimesed puudust tunnevad. HTTPS-i kaudu laaditav leht võib siiski tõmmata http URL-ilt pilte, fonte või skripte ning brauser blokeerib need või muudab kogu lehe turvanäidiku madalamaks. Kontrollige võrgupaneelil ebaõnnestunud päringuid ja parandage ressursside viited nende omanikule, selle asemel, et eeldada, et aadressiriba kirjeldab iga päringut. Käitataval saidil tähendab see CMS-is või mallis salvestatud URL-ide parandamist, selle asemel, et neid brauseris ümber kirjutada. Kui te ei saa allikat muuta, salvestage segatud sisu teadaoleva lünkana, sest lehe tabalukk, mis tõmbab lihtteksti ressursse, on vale signaal.

4. samm: mida HSTS lisab ja mida mitte

HSTS on pigem saidipoliitika kui brauseri eelistus ja see on siin ainus mehhanism, mis säilib värskel profiilil sisestatud http://. Kui brauser on näinud hosti jaoks Strict-Transport-Security päist, kirjutab ta hilisemad päringud enne saatmist ümber https-i, mis on täpselt see omadus, mida soovite. See ei tee midagi hosti jaoks, mida brauser pole kunagi külastanud, ega midagi teistsuguse hostinime puhul, mis teenindab sama rakendust.

Kontrollige, mida päritolu saadab curl -sSI https://example.com | grep -i strict-transport-security-ga. Puuduv päis on serveri muudatus, mida klient ei saa installida. Kui see on olemas, lugege max-age ja seda, kas includeSubDomains on määratud, sest külastuste vahel aegub lühike maksimaalne vanus ja puuduv includeSubDomains jätab kõik alamdomeenid kaitsmata. RFC 6797 määrab, kuidas kasutajaagent poliitikat rakendab ja mida ta võib ignoreerida. Eellaadimine on eraldi kohustus, seega kontrollige olekut hstspreload.org API kaudu, enne kui lubate kellelegi, et domeen on loendis.

Kinnitamine ja tagasivõtmine

Tagasivõtmine on kliendi seadete jaoks odav ja HSTS-i jaoks kallis. Ainult HTTPS-režiimi väljalülitamine taastab kohe varasema käitumise; pikk maksimaalne vanus seda ei tee ja külastajad, kes selle juba said, jätkavad versiooni uuendamist, kuni see aegub.

Nii et enne tehtuks nimetamist kontrollige järjekorda. Laadige uuesti vahemälust ja kinnitage, et võrgupaneeli esimene päring on https ilma eelneva ümbersuunamiseta. Seejärel kontrollige alamdomeeni, sest includeSubDomains on koht, kus need eeskirjad osutuvad tavaliselt eeldatust kitsamaks. Seejärel kontrollige ühte lehte, mis tõmbab kolmandate osapoolte varasid, kuna segasisu on tõrge, mis jääb ellu iga teise parandusega.

Kui esimene päring on pärast kõike seda endiselt http, ei ole klient enam muutuja: link, millel inimesed klõpsavad, on see. Otsige hallatavatest kohtadest hostinime http-vormi, värskendage neid ja testige uuesti sama külma vahemälu laadimisega. Hoidke VPN-i küsimus kogu ulatuses eraldi, sest tunnel muudab seda, kes taotlust näeb, ega muuda kunagi seda, kas taotlus on krüptitud. Piletisse tuleb lisada, et esimene päring on oluline ja ümbersuunamine on ainult juba saadetud päringu kviitung.