Paano Gawing Unang Kahilingan ang HTTPS sa pamamagitan ng VPN
Ang HTTPS-only mode, totoong HTTPS na mga bookmark at HSTS ay tatlong magkakaibang pag-aayos. Patakbuhin ang mga ito sa pagkakasunud-sunod upang ang unang kahilingan ay naka-encrypt, hindi na-redirect.
Isang browser na unang nag-type ng http:// at dumarating sa https:// pagkatapos ng pag-redirect ay nagpadala na ng isang kahilingan sa clear, at hindi iyon binabago ng VPN. Pinoprotektahan ng tunel ang binti mula sa kliyente hanggang sa exit node; hindi ito nag-e-encrypt ng anumang bagay sa itaas ng layer ng transportasyon, kaya nakikita pa rin ng isang tagamasid sa pagitan ng exit at pinagmulan ang plaintext hop. Ang paggawa ng HTTPS na unang kahilingan ay isang pagbabago sa panig ng kliyente na may tatlong bahagi: isang tunay na HTTPS address, upgrade mode ng browser, at sariling patakaran ng site. Ang mga hakbang sa ibaba ay ang pagkakasunud-sunod na ginagamit ko, bawat isa ay may tseke na nagsasabi sa iyo kung tumagal ito.
Hakbang 1: kumpirmahin kung ano talaga ang unang kahilingan
Bago baguhin ang anuman, tingnan kung ano ang ipinapadala ng browser. Buksan ang panel ng network na na-reload ang pahina mula sa isang malamig na cache at basahin ang unang hilera: kung ang scheme ay http at ang status ay 301 o 308, ang lahat pagkatapos ng row na iyon ay pangalawang kahilingan. Ang curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com ay gumagawa ng parehong sequence sa labas ng browser at nagpi-print ng URL kung saan ka nagtapos.
Dalawang resulta ang posible at kailangan nila ng magkaibang pag-aayos. Kung ang site ay naghahatid ng HTTPS sa parehong host, ang pagsasaayos ay ihinto ang pag-publish ng HTTP form: i-update ang bookmark, ang link ng wiki, ang desktop shortcut at ang template ng email na na-click ng mga tao. Kung hindi naghahatid ng HTTPS ang site, walang setting ng browser ang gagawa nito, at ang tapat na sagot ay ang patutunguhan ang problema. Huwag isulat ang pangalawang kaso nang may eksepsiyon, dahil ang isang pagbubukod sa sertipiko sa isang pahina ng account ay nagko-convert ng problema sa transportasyon sa isang problema sa kredensyal. Isulat kung nasaang kaso ka bago mo pindutin ang isang setting.
Hakbang 2: i-on ang HTTPS-only mode ng browser
Ang upgrade mode ay ang pangalawang bahagi, at ang mga mode ay hindi mapapalitan. Suriin kung ano ang ginagawa ng sa iyo bago mo ito paganahin: tahimik na mag-upgrade, mag-upgrade nang may babala, o tumangging mag-load.
Sa Firefox, nakatira ang mga kontrol sa likod ng about:config at sa pahina ng mga setting ng privacy, kasama ang dom.security.https_only_mode bilang switch at mga pagbubukod sa bawat site na pinamamahalaan mula sa menu ng padlock. Sa Chrome at Edge ang parehong ideya ay makikita sa ilalim ng Mga Setting, Privacy at seguridad, Seguridad, na may label na Palaging gumamit ng mga secure na koneksyon. Anuman ang label, i-verify ang gawi laban sa isang host na sumasagot lamang sa port 80, dahil ang isang mode na nag-a-upgrade at pagkatapos ay tahimik na bumabalik ay hindi ang proteksyon na sa tingin mo ay pinagana mo. Ang dokumentasyon ng Firefox HTTPS-Only ay nagsasaad ng pag-upgrade, babala at pagbubukod sa pag-uugali para sa browser na iyon.
Hakbang 3: ayusin ang mga mapagkukunan, hindi lamang ang address bar
Kapag nabigo ang isang pag-upgrade, basahin ang eksaktong error sa halip na ang address bar. Ang isang host na walang HTTPS listener, isang hostname na hindi tumutugma sa certificate at isang nag-expire na chain ay gumagawa ng iba't ibang mga mensahe at pagmamay-ari ng iba't ibang mga may-ari. Tanging ang una ay isang server-side gap; ang pangalawa ay karaniwang isang bookmark na hindi kailanman na-update; ang pangatlo ay isang problema sa pag-renew kung saan walang kaugnayan ang koneksyon sa VPN.
Huwag magdagdag ng certificate exception sa isang account site dahil naka-on ang VPN. Ang pagbubukod ay hindi pinapagana ang tseke na makakahuli nang eksakto sa pagharang na dapat pigilan ng VPN.
Ang ikatlong bahagi ay nasa loob ng pahina, at ito ang pinalampas ng mga tao. Ang isang page na naglo-load sa HTTPS ay maaari pa ring kumuha ng mga larawan, font o script mula sa isang http URL, at maaaring iba-block sila ng browser o i-downgrade ang security indicator para sa buong page. Siyasatin ang mga nabigong kahilingan sa network panel at ayusin ang mga resource reference sa kanilang may-ari sa halip na ipagpalagay na ang address bar ay naglalarawan sa bawat kahilingan. Sa isang site na pinapatakbo mo, nangangahulugan iyon ng pagwawasto sa mga nakaimbak na URL sa CMS o sa template sa halip na muling isulat ang mga ito sa browser. Kung hindi mo mababago ang pinagmulan, itala ang pinaghalong nilalaman bilang isang kilalang puwang, dahil ang isang padlock sa ibabaw ng isang pahina na kumukuha ng mga mapagkukunan ng plaintext ay isang maling signal.
Hakbang 4: kung ano ang idinaragdag ng HSTS, at kung ano ang hindi nito
Ang HSTS ay isang patakaran sa site sa halip na isang kagustuhan sa browser, at ito ang tanging mekanismo dito na nananatili sa isang na-type na http:// sa isang bagong profile. Kapag nakakita na ang isang browser ng Strict-Transport-Security na header para sa isang host, isinusulat nito muli ang mga kahilingan sa paglaon sa https bago ipadala ang mga ito, na eksaktong property na gusto mo. Wala itong ginagawa para sa isang host na hindi pa nabisita ng browser, at wala para sa ibang hostname na nagsisilbi sa parehong application.
Tingnan kung ano ang ipinapadala ng pinanggalingan gamit ang curl -sSI https://example.com | grep -i strict-transport-security. Ang nawawalang header ay isang pagbabago ng server at hindi isang bagay na maaaring i-install ng isang kliyente. Kung naroroon ito, basahin ang max-age at kung nakatakda ang includeSubDomains, dahil ang isang maikling max-edad ay mag-e-expire sa pagitan ng mga pagbisita at isang nawawalang includeSubDomains ay nag-iiwan sa bawat subdomain na walang proteksyon. Tinutukoy ng RFC 6797 kung paano inilalapat ng isang user agent ang patakaran at kung ano ang maaaring balewalain nito. Ang preload ay isang hiwalay na pangako, kaya suriin ang status sa pamamagitan ng hstspreload.org API bago ipangako sa sinuman na ang isang domain ay nasa listahan.
Verification at rollback
Murang ang rollback para sa mga setting ng kliyente at mahal para sa HSTS. Kapag na-off ang HTTPS-only na mode, ire-restore kaagad ang dating gawi; ang isang mahabang max-age ay hindi, at ang mga bisitang nakatanggap na nito ay patuloy na nag-a-upgrade hanggang sa ito ay mag-expire.
Kaya i-verify nang maayos bago ito tawaging tapos na. I-reload mula sa isang malamig na cache at kumpirmahin ang unang kahilingan sa panel ng network ay https na walang naunang pag-redirect. Pagkatapos ay suriin ang isang subdomain, dahil ang includeSubDomains ay kung saan ang mga patakarang ito ay karaniwang lumalabas na mas makitid kaysa sa ipinapalagay. Pagkatapos, tingnan ang isang page na kumukuha ng mga third-party na asset, dahil ang pinaghalong content ay ang kabiguan na nananatili sa bawat pag-aayos.
Kung ang unang kahilingan ay http pa rin pagkatapos ng lahat ng iyon, ang kliyente ay hindi na ang variable: ang link na na-click ng mga tao ay. Maghanap sa mga lugar na kinokontrol mo para sa http form ng hostname, i-update ang mga ito, at muling subukan gamit ang parehong cold-cache reload. Panatilihing hiwalay ang tanong sa VPN sa kabuuan, dahil nagbabago ang tunnel kung sino ang makakakita sa kahilingan at hindi magbabago kung naka-encrypt ang kahilingan. Ang linyang ilalagay sa ticket ay ang unang kahilingan ay ang mahalaga, at ang pag-redirect ay isang resibo lamang para sa kahilingang naipadala na.