Kuinka tehdä HTTPS:stä ensimmäinen pyyntö VPN:n kautta

Selain, joka kirjoittaa ensin http:// ja siirtyy osoitteeseen https:// sen jälkeen, kun uudelleenohjaus on jo lähettänyt yhden pyynnön selkeästi, eikä VPN muuta sitä. Tunneli suojaa jalkaa asiakkaasta poistumissolmuun; se ei salaa mitään siirtokerroksen yläpuolella, joten havainnoitsija poistumiskohdan ja alkuperän välillä näkee silti selväkielihypyn. HTTPS:n tekeminen ensimmäiseksi pyynnöksi on asiakaspuolen muutos, jossa on kolme osaa: todellinen HTTPS-osoite, selaimen päivitystila ja sivuston oma käytäntö. Alla olevat vaiheet ovat käyttämäni järjestyksessä, ja jokaisessa on sekki, joka kertoo, kestikö se.

Vaihe 1: vahvista, mikä ensimmäinen pyyntö todella on

Ennen kuin muutat mitään, katso, mitä selain lähettää. Avaa verkkopaneeli, jossa sivu on ladattu uudelleen kylmästä välimuistista, ja lue ensimmäinen rivi: jos malli on http ja tila on 301 tai 308, kaikki tämän rivin jälkeen on toinen pyyntö. curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com toistaa saman sarjan selaimen ulkopuolella ja tulostaa URL-osoitteen, johon päädyit.

Kaksi lopputulosta on mahdollista, ja ne vaativat erilaisia korjauksia. Jos sivusto palvelee HTTPS:ää samassa isännässä, korjaus on lopettaa HTTP-lomakkeen julkaiseminen: päivitä kirjanmerkki, wikilinkki, työpöydän pikakuvake ja sähköpostimalli, jota ihmiset napsauttavat. Jos sivusto ei palvele HTTPS:ää ollenkaan, mikään selainasetus ei luo sitä, ja rehellinen vastaus on, että kohde on ongelma. Älä käsittele toista tapausta poikkeuksella, koska tilisivulla oleva varmennepoikkeus muuttaa kuljetusongelman valtuustietoongelmaksi. Kirjoita muistiin, missä tapauksessa olet, ennen kuin kosketat asetusta.

Vaihe 2: ota käyttöön selaimen Vain HTTPS -tila

Päivitystila on toinen osa, eivätkä tilat ole keskenään vaihdettavissa. Tarkista, mitä omasi tekee ennen kuin otat sen käyttöön: päivitä äänettömästi, päivitä varoituksella tai kieltäydy lataamisesta.

Firefoxissa säätimet sijaitsevat about:config takana ja tietosuoja-asetussivulla, dom.security.https_only_mode kytkimenä ja sivustokohtaisia poikkeuksia hallitaan riippulukkovalikosta. Chromessa ja Edgessä sama idea on kohdassa Asetukset, Tietosuoja ja suojaus, Suojaus, jossa lukee Käytä aina suojattuja yhteyksiä. Tarkasta mikä tahansa, tarkista isäntä, joka vastaa vain portissa 80, koska tila, joka päivittyy ja palaa sitten hiljaa, ei ole se suojaus, jonka luulet ottavasi käyttöön. Vain Firefoxin HTTPS-dokumentaatiossa kerrotaan kyseisen selaimen päivitys-, varoitus- ja poikkeuskäyttäytymisestä.

Vaihe 3: korjaa resurssit, ei vain osoitepalkkia

Kun päivitys epäonnistuu, lue tarkka virhe osoitepalkin sijaan. Isäntä, jolla ei ole HTTPS-kuuntelijaa, isäntänimi, joka ei vastaa varmennetta, ja vanhentunut ketju tuottavat erilaisia viestejä ja kuuluvat eri omistajille. Vain ensimmäinen on palvelinpuolen aukko; toinen on yleensä kirjanmerkki, jota ei koskaan päivitetty; kolmas on uusimisongelma, johon VPN-yhteys ei liity.

Älä lisää varmennepoikkeusta tilisivustoon, koska VPN on päällä. Poikkeus poistaa käytöstä tarkistuksen, joka olisi saanut kiinni juuri sen sieppauksen, jonka VPN on tarkoitus estää.

Kolmas osa on sivun sisällä, ja se on se, jota ihmiset kaipaavat. HTTPS:n kautta latautuva sivu voi silti noutaa kuvia, kirjasimia tai komentosarjoja http-URL-osoitteesta, ja selain joko estää ne tai alentaa koko sivun suojausilmaisinta. Tarkista epäonnistuneet pyynnöt verkkopaneelista ja korjaa resurssiviittaukset niiden omistajalle sen sijaan, että olettaisit, että osoiterivi kuvaa jokaista pyyntöä. Sivustolla, jota käytät, tämä tarkoittaa, että tallennetut URL-osoitteet korjataan sisällönhallintajärjestelmään tai malliin sen sijaan, että kirjoitat ne uudelleen selaimeen. Jos et voi vaihtaa lähdettä, tallenna sekoitettu sisältö tunnetuksi aukkoksi, koska riippulukko sivun päälle, joka vetää selkotekstiresursseja, on väärä signaali.

Vaihe 4: mitä HSTS lisää ja mitä ei

HSTS on sivustokäytäntö pikemminkin kuin selainasetus, ja se on ainoa mekanismi, joka selviää kirjoitetusta http://-osoitteesta uudessa profiilissa. Kun selain on nähnyt isännän Strict-Transport-Security-otsikon, se kirjoittaa myöhemmät pyynnöt uudelleen https-muotoon ennen niiden lähettämistä, mikä on juuri haluamasi ominaisuus. Se ei tee mitään isännälle, jossa selain ei ole koskaan käynyt, eikä mitään eri isäntänimelle, joka palvelee samaa sovellusta.

Tarkista, mitä alkuperä lähettää curl -sSI https://example.com | grep -i strict-transport-security:lla. Puuttuva otsikko on palvelimen muutos, eikä asiakas voi asentaa sitä. Jos se on olemassa, lue max-age ja onko includeSubDomains asetettu, koska lyhyt enimmäisikä umpeutuu käyntien välillä ja puuttuva includeSubDomains jättää kaikki aliverkkotunnukset suojaamattomiksi. RFC 6797 määrittää, kuinka käyttäjäagentti soveltaa käytäntöä ja mitä se voi jättää huomiotta. Esilataus on erillinen sitoumus, joten tarkista tila hstspreload.org API:n kautta ennen kuin lupaat kenellekään, että verkkotunnus on luettelossa.

Vahvistus ja palautus

Palautus on edullista asiakasasetuksille ja kallista HSTS:lle. Vain HTTPS -tilan poistaminen käytöstä palauttaa aiemman toiminnan välittömästi; pitkä enimmäisikä ei, ja sen jo saaneet vierailijat jatkavat päivitystä, kunnes se vanhenee.

Tarkista siis järjestyksessä ennen kuin kutsut sen valmiiksi. Lataa uudelleen kylmästä välimuistista ja varmista, että verkkopaneelin ensimmäinen pyyntö on https ilman edeltävää uudelleenohjausta. Tarkista sitten aliverkkotunnus, koska includeSubDomains on paikka, jossa nämä käytännöt yleensä osoittautuvat oletettua kapeammiksi. Tarkista sitten yksi sivu, joka hakee kolmannen osapuolen omaisuutta, koska sekasisältö on vika, joka kestää kaikki muut korjaukset.

Jos ensimmäinen pyyntö on edelleen http kaiken tämän jälkeen, asiakas ei ole enää muuttuja: linkki, jota ihmiset napsauttavat, on. Etsi hallitsemistasi paikoista isäntänimen http-muoto, päivitä ne ja testaa uudelleen samalla kylmävälimuistilatauksella. Pidä VPN-kysymys erillään kauttaaltaan, koska tunneli muuttaa sitä, kuka näkee pyynnön eikä koskaan muuta sitä, onko pyyntö salattu. Lippuun on lisättävä se, että ensimmäinen pyyntö on se, jolla on merkitystä, ja uudelleenohjaus on vain kuitti jo lähetetystä pyynnöstä.