Hogyan lehet a HTTPS-t az első kéréssé tenni VPN-en keresztül

Egy böngésző, amely először a http:// címet írja be, és a https:// címre érkezik, miután egy átirányítás már elküldött egy kérést, és a VPN nem változtat ezen. Az alagút védi a lábat a klienstől a kilépési csomópontig; nem titkosít semmit a szállítási réteg felett, így a kilépés és az origó közötti megfigyelő továbbra is látja a plaintext ugrást. A HTTPS első kérése egy kliensoldali változtatás, amely három részből áll: valódi HTTPS-cím, a böngésző frissítési módja és a webhely saját házirendje. Az alábbi lépések az általam használt sorrendet mutatják, mindegyikhez tartozik egy csekk, amely megmondja, hogy sikerült-e.

1. lépés: ellenőrizze, hogy valójában mi is az első kérés

Mielőtt bármit módosítana, nézze meg, mit küld a böngésző. Nyissa meg a hálózati panelt a hideggyorsítótárból újratöltött oldallal, és olvassa el az első sort: ha a séma http, és az állapot 301 vagy 308, akkor a sor után minden egy második kérés. A curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com ugyanazt a sorozatot reprodukálja a böngészőn kívül, és kinyomtatja azt az URL-t, amelyre végül eljutott.

Két kimenetel lehetséges, és ezek különböző javításokat igényelnek. Ha a webhely HTTPS-t szolgál ki ugyanazon a gazdagépen, a megoldás az, hogy leállítjuk a HTTP-űrlap közzétételét: frissítse a könyvjelzőt, a wikihivatkozást, az asztali parancsikont és az e-mail-sablont, amelyre az emberek kattintanak. Ha az oldal egyáltalán nem szolgálja ki a HTTPS-t, akkor semmilyen böngészőbeállítás nem hozza létre, és az őszinte válasz az, hogy a cél a probléma. A második esetet ne írja le kivételekkel, mert a fiókoldalon lévő tanúsítványkivétel a szállítási problémát hitelesítési problémává alakítja. Mielőtt megérint egy beállítást, írja le, hogy melyik esetben van.

2. lépés: kapcsolja be a böngésző csak HTTPS-módját

A frissítési mód a második rész, és a módok nem cserélhetők fel. Mielőtt engedélyezné, ellenőrizze, hogy a tiéd mit csinál: csendesen frissít, figyelmeztetéssel frissít, vagy megtagadja a betöltést.

A Firefoxban a vezérlők a about:config mögött és az adatvédelmi beállítások oldalon találhatók, a dom.security.https_only_mode kapcsolóval, és a lakatmenüből kezelhető webhelyenkénti kivételek. A Chrome-ban és az Edge-ben ugyanez az ötlet található a Beállítások, Adatvédelem és biztonság, Biztonság alatt, a Mindig használjon biztonságos kapcsolatokat címkével. Bármi is legyen a címke, ellenőrizze a viselkedést egy olyan gazdagéppel szemben, amely csak a 80-as porton válaszol, mert az a mód, amely frissít, majd csendben visszaesik, nem az a védelem, amelyet Ön szerint engedélyezett. A Firefox HTTPS-Only dokumentáció leírja az adott böngésző frissítési, figyelmeztetési és kivételes viselkedését.

3. lépés: javítsa az erőforrásokat, ne csak a címsávot

Ha a frissítés sikertelen, a címsáv helyett olvassa el a pontos hibát. A HTTPS-figyelő nélküli gazdagép, a tanúsítvánnyal nem egyező gazdagépnév és egy lejárt lánc különböző üzeneteket állít elő, és különböző tulajdonosokhoz tartozik. Csak az első egy szerveroldali rés; a második általában egy könyvjelző, amelyet soha nem frissítettek; a harmadik egy megújítási probléma, amelyhez a VPN-kapcsolat irreleváns.

Ne adjon hozzá tanúsítványkivételt egy fiókhelyhez, mert a VPN be van kapcsolva. A kivétel letiltja azt az ellenőrzést, amely pontosan azt az elfogást fogta volna, amelyet a VPN meg akart akadályozni.

A harmadik rész az oldalon belül található, és ez az, amit az emberek hiányolnak. A HTTPS-en keresztül betöltődő oldal továbbra is képes képeket, betűtípusokat vagy szkripteket lekérni egy http URL-ről, és a böngésző vagy blokkolja őket, vagy leminősíti a teljes oldal biztonsági jelzőjét. Vizsgálja meg a sikertelen kéréseket a hálózati panelen, és javítsa ki az erőforrás-hivatkozásokat a tulajdonosnál, ahelyett, hogy azt feltételezné, hogy a címsor minden kérést leír. Az Ön által futtatott webhelyen ez a CMS-ben vagy a sablonban tárolt URL-ek javítását jelenti ahelyett, hogy átírná őket a böngészőben. Ha nem tudja megváltoztatni a forrást, rögzítse a kevert tartalmat ismert hiányosságként, mert az oldal feletti lakat, amely egyszerű szöveges forrásokat húz, hamis jelzés.

4. lépés: mit ad hozzá a HSTS, és mit nem

A HSTS egy webhelyházirend, nem pedig böngészőpreferencia, és ez az egyetlen mechanizmus, amely túléli a beírt http://-t egy friss profilon. Ha egy böngésző Strict-Transport-Security fejlécet látott egy gazdagéphez, átírja a későbbi kéréseket https-re, mielőtt elküldené őket, ami pontosan a kívánt tulajdonság. Semmit nem tesz egy olyan gazdagép esetében, amelyet a böngésző soha nem látogatott meg, és semmit nem tesz egy másik gazdagépnévvel, amely ugyanazt az alkalmazást szolgálja ki.

Ellenőrizze, hogy az eredet mit küld a curl -sSI https://example.com | grep -i strict-transport-security kóddal. A hiányzó fejléc a kiszolgáló módosítása, és nem olyasmi, amit az ügyfél telepíthet. Ha jelen van, olvassa el a max-age és azt, hogy a includeSubDomains be van-e állítva, mert a látogatások között egy rövid maximális korhatár lejár, a hiányzó includeSubDomains pedig minden aldomaint védelem nélkül hagy. Az RFC 6797 meghatározza, hogy a felhasználói ügynök hogyan alkalmazza a házirendet, és mit hagyhat figyelmen kívül. Az előbetöltés külön kötelezettségvállalás, ezért ellenőrizze az állapotot a hstspreload.org API-n keresztül, mielőtt bárkinek megígérné, hogy egy domain szerepel a listán.

Ellenőrzés és visszaállítás

A visszaállítás olcsó az ügyfélbeállításokhoz, és drága a HSTS-hez. A csak HTTPS mód kikapcsolása azonnal visszaállítja a korábbi viselkedést; a hosszú max-életkor nem, és a látogatók, akik már megkapták, folyamatosan frissítik, amíg le nem jár.

Tehát ellenőrizze a sorrendet, mielőtt késznek nevezné. Töltse be újra a hideg gyorsítótárból, és ellenőrizze, hogy a hálózati panelen az első kérés https-e, előzetes átirányítás nélkül. Ezután ellenőrizze az aldomaint, mert az includeSubDomains az a hely, ahol ezek a házirendek általában szűkebbek a feltételezettnél. Ezután ellenőrizze az egyik oldalt, amely harmadik féltől származó eszközöket gyűjt, mivel a vegyes tartalom az a hiba, amely minden más javítást túlél.

Ha ezek után az első kérés továbbra is http, akkor már nem az ügyfél a változó: az a hivatkozás, amelyre az emberek kattintanak. Keresse meg az Ön által ellenőrzött helyeken a gazdagépnév http-formáját, frissítse őket, és tesztelje újra ugyanazzal a hideggyorsítótár-újratöltéssel. Tartsa külön a VPN-kérdést, mert az alagút megváltoztatja, hogy ki láthatja a kérést, és soha nem változtatja meg, hogy a kérés titkosított-e. A jegybe be kell írni, hogy az első kérés számít, az átirányítás pedig csak a már elküldött kérés nyugtája.