Näin otat HSTS:n käyttöön lukitsematta itseäsi ulos

HSTS on yksinkertainen, kunnes se ei ole

HTTP Strict Transport Security, tavallisesti lyhennettynä HSTS, kertoo selaimille: ”käytä tällä sivustolla aina HTTPS:ää.” Kun selain saa otsakkeen kelvollisen HTTPS-yhteyden kautta, se muistaa säännön määrittämäsi ajan.

Se on hyödyllistä. Se estää protokollan alentamishyökkäyksiä, vähentää tahattomia suojaamattomia pyyntöjä ja välttää kiusallisen hetken, jossa käyttäjä kirjoittaa example.com ja koskettaa hetken tavallista HTTP:tä ennen uudelleenohjausta.

Se on myös sitkeä. Jos julkaiset väärän HSTS-käytännön, selaimet voivat jatkaa sen noudattamista pitkään sen jälkeen, kun olet poistanut otsakkeen palvelimeltasi. Näin tiimit lukitsevat itsensä ulos: eivät aivan omasta ylläpitopaneelistaan, vaan käyttäjien selaimista, aliverkkotunnuksista, staging-järjestelmistä, vanhoista päätepisteistä ja unohdetuista palveluista, jotka eivät ole valmiita pakotettuun HTTPS:ään.

Tavoitteena ei ole välttää HSTS:ää. Tavoitteena on ottaa se käyttöön migraationa, ei kytkimenä.

Mitä HSTS-otsake oikeasti tekee

Tyypillinen HSTS-otsake näyttää tältä:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Siinä on kolme tärkeää osaa:

• max-age: kuinka pitkään, sekunteina, selaimen tulee pakottaa HTTPS tälle isännälle.
• includeSubDomains: koskeeko sääntö myös jokaista aliverkkotunnusta.
• preload: signaali siitä, että haluat verkkotunnuksen mukaan selainten preload-listoille.

Selain luottaa tähän otsakkeeseen vain, kun se saa sen kelvollisen HTTPS:n yli. Jos varmenne on virheellinen, vanhentunut tai väärälle nimelle, selaimen ei pitäisi hyväksyä uutta HSTS-käytäntöä kyseisestä vastauksesta.

Kun käytäntö on tallennettu, tulevat yritykset vierailla osoitteessa http://example.com päivitetään selaimessa osoitteeseen https://example.com ennen pyynnön lähettämistä. Siinä on yksityisyyshyöty: suojaamaton pyyntö ei koskaan poistu laitteelta.

Uloslukitusskenaariot, joita kannattaa välttää

Useimmat HSTS-ongelmat eivät johdu pääsivustosta. Ne tapahtuvat reunoilla.

1. Unohtunut aliverkkotunnus ei ole HTTPS-valmis

includeSubDomains kuulostaa siistiltä, mutta se on ehdoton. Jos asetat sen verkkotunnukselle example.com, se koskee seuraavia:

• www.example.com
• api.example.com
• old-crm.example.com
• printer-setup.example.com
• staging.example.com
• kaikkea muuta kyseisen verkkotunnuksen alla

Jos mikään näistä isännistä ei pysty tarjoamaan kelvollista HTTPS:ää, käyttäjät, joiden selaimeen HSTS-käytäntö on välimuistitettu, eivät pääse niihin HTTP:n yli.

2. Varmenne vanhenee

Ilman HSTS:ää käyttäjät joskus ohittavat varmennevaroituksia. Se ei ole hyvä tietoturvakäytäntö, mutta sitä tapahtuu.

HSTS:n kanssa modernit selaimet eivät salli varmennevirheiden helppoa ohittamista kyseiselle isännälle. Se on tarkoituskin. Se tarkoittaa myös, että varmenteiden uusimisen täytyy olla tylsää, valvottua ja testattua.

3. Staging- tai sisäiset työkalut sijaitsevat tuotantoverkkotunnuksen alla

Sisäisten työkalujen sijoittaminen alle *.example.com voi muuttua hankalaksi, kun pääverkkotunnus käyttää includeSubDomains-direktiiviä. Jos nämä työkalut käyttävät itse allekirjoitettuja varmenteita, yksityisiä varmentajia, vanhoja TLS-määrityksiä tai eivät lainkaan HTTPS:ää, HSTS paljastaa oikotien.

Tämä on yksi syy siihen, miksi monet tiimit pitävät sisäiset ja kokeelliset järjestelmät erillisessä verkkotunnuksessa, jolla on oma tietoturvakäytäntönsä.

4. Preloadia käsitellään rutiininomaisena valintaruutuna

HSTS preload ei ole vain yksi direktiivi lisää. Se tarkoittaa, että verkkotunnuksesi voidaan toimittaa selainten mukana HTTPS-only-tilassa ennen kuin yksikään käyttäjä on vieraillut sivustollasi.

Se sulkee ”ensimmäisen käynnin” aukon, mutta sen peruminen on paljon vaikeampaa. Poistuminen preload-listoilta voi kestää viikkoja tai kuukausia ennen kuin muutos saavuttaa käyttäjät, riippuen selainten julkaisusykleistä. Preload sopii vakaille ja kypsille verkkotunnuksille. Se ei sovi sivustolle, joka vielä selvittää aliverkkotunnustensa inventaariota.

Turvallinen käyttöönotösuunnitelma

Vaihe 1: Auditoi jokainen hallitsemasi isäntänimi

Ennen includeSubDomains-direktiivin asettamista listaa jokainen verkkotunnuksen alla oleva isäntänimi. DNS-tietueet ovat alku, mutta eivät koko tarina. Tarkista CDN-määritykset, hosting-hallintapaneelit, sähköpostiin liittyvät isäntänimet, vanhat markkinointityökalut, tallennusbucketit ja sisäinen dokumentaatio.

Vastaa jokaisesta isäntänimestä:

• Palveleeko se HTTP:tä, HTTPS:ää vai molempia?
• Onko HTTPS-varmenne kelvollinen ja uusitaanko se automaattisesti?
• Ohjaako se HTTP:n HTTPS:ään siististi?
• Onko sen tarkoitus olla julkinen?
• Tarvitaanko sitä edelleen?

Jos tiimilläsi on jo tuotannon otsakkeiden debuggaustottumuksia, tämä sopii luontevasti uudelleenohjausten ja otsakkeiden tarkistusten viereen. Käsittelimme sitä työnkulkua artikkelissa pieni työkalupakki uudelleenohjausten ja HTTP-otsakkeiden debuggaamiseen tuotannossa.

Vaihe 2: Korjaa HTTPS ennen HSTS:n lisäämistä

HSTS ei tee rikkinäisestä HTTPS-määrityksestä turvallista. Se vain tekee HTTPS:stä pakollisen.

Ennen käyttöönottoa varmista:

• TLS-varmenteet kattavat oikeat isäntänimet.
• Varmenteet uusiutuvat automaattisesti.
• HTTP ohjautuu HTTPS:ään yhdellä siistillä hypyllä, jos mahdollista.
• Kanonisen isännän uudelleenohjaukset ovat johdonmukaisia, esimerkiksi non-www to www, tai päinvastoin.
• Sovelluksen resurssit eivät riipu suojaamattomista http://-URL-osoitteista.

Sekasisältö on harvinaisempaa kuin ennen, mutta sitä näkyy edelleen vanhoissa CMS-teemoissa, analytiikkapätkissä, upotetussa mediassa ja kovakoodatuissa kuvapoluissa.

Vaihe 3: Aloita hyvin lyhyellä max-age-arvolla

Älä aloita yhdestä vuodesta. Aloita viidestä minuutista:

Strict-Transport-Security: max-age=300

Ota se käyttöön vain sillä isäntänimellä, jota testaat, tavallisesti kanonisella tuotantosivustolla. Jätä includeSubDomains toistaiseksi pois.

Testaa sitten oikeilla selaimilla ja komentorivipyynnöillä:

curl -I https://example.com

Sinun pitäisi nähdä täsmälleen yksi Strict-Transport-Security-otsake. Sovelluspalvelimen ja CDN:n tuottamat päällekkäiset HSTS-otsakkeet ovat yleinen hämmennyksen lähde. Selaimet yleensä soveltavat efektiivistä käytäntöä, mutta häiriötä debuggaavat ihmiset eivät tarvitse epäselvyyttä.

Vaihe 4: Kasvata vähitellen

Jos mikään ei hajoa, kasvata kestoa vaiheittain:

Strict-Transport-Security: max-age=86400

Sitten:

Strict-Transport-Security: max-age=604800

Sitten ehkä:

Strict-Transport-Security: max-age=2592000

Käytännöllinen aikataulu on:

• 5 minuuttia
• 1 päivä
• 1 viikko
• 1 kuukausi
• 6 kuukautta tai 1 vuosi

Kiirehtimisestä ei saa palkintoa. Vaiheittaisen käyttöönoton koko tarkoitus on antaa valvonnalle, tukipostilaatikolle ja reunatapauksille aikaa kertoa, mitä tarkistuslistasi ohitti.

Vaihe 5: Lisää includeSubDomains vasta, kun auditointi on todellinen

Kun jokainen julkinen aliverkkotunnus on HTTPS-valmis, voit harkita seuraavaa:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Tässä kohdassa kannattaa olla varovainen. Jos yksi vanha palvelu tarvitsee edelleen HTTP:tä, älä lisää includeSubDomains-direktiiviä pääverkkotunnukseen. Joko migroi palvelu, siirrä se toiseen verkkotunnukseen tai hyväksy, että HSTS-käytäntösi täytyy toistaiseksi pysyä kapeampana.

Tietoturvaotsakkeiden tulisi heijastaa todellisuutta. Niitä ei pitäisi käyttää motivaatiopostereina infrastruktuurille, jonka toivot saavasi myöhemmin.

Vaihe 6: Käsittele preloadia erillisenä projektina

Harkitse preloadia vain, kun kaikki seuraavat pitävät paikkansa:

• Verkkotunnus ja kaikki aliverkkotunnukset tukevat kelvollista HTTPS:ää.
• HTTP ohjautuu HTTPS:ään.
• HSTS-otsake käyttää vähintään 31536000 sekunnin max-age-arvoa.
• Otsake sisältää includeSubDomains.
• Otsake sisältää preload.
• Olet varma, ettet tarvitse tavallista HTTP:tä missään verkkotunnuksen alla.

Preload-valmis otsake näyttää tältä:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Preload-listalle lähettäminen on pitkäaikainen sitoumus. Jos sivusto on kampanjamikrosivusto, väliaikainen tuoteverkkotunnus tai verkkotunnus, jonka omistusrajat ovat epäselvät, jätä se väliin.

Määritysesimerkkejä

Nginx

Käytä always, jotta otsake lähetetään myös virhevastauksissa:

add_header Strict-Transport-Security "max-age=300" always;

Kun käyttöönotto on vakaa:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Apache

Kun mod_headers on käytössä:

Header always set Strict-Transport-Security "max-age=300"

Myöhemmin:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

CDN tai edge-alusta

Jos CDN asettaa vastausotsakkeita, hallitse HSTS:ää mieluiten yhdessä paikassa. Älä aseta yhtä käytäntöä originissa ja toista edgessä, ellei sinulla ole siihen hyvin selkeää syytä.

Tarkista myös, soveltaako CDN otsakkeita uudelleenohjauksiin, välimuistitettuihin virheisiin ja mukautettuihin virhesivuihin. Tuotantosivusto ei ole vain sen 200 OK -vastaus.

Miten HSTS perutaan turvallisesti

Jos sinun täytyy poistaa HSTS käytöstä, lähetä:

Strict-Transport-Security: max-age=0

Mutta siinä on koukku: selaimen täytyy onnistua saavuttamaan sivusto kelvollisen HTTPS:n yli saadakseen kyseisen otsakkeen. Jos HTTPS itsessään on rikki, käyttäjät, joilla on välimuistitettu HSTS-käytäntö, eivät voi hakea ohjetta, joka tyhjentäisi sen.

Siksi tavallinen palautumisjärjestys on:

1. Palauta kelvollinen HTTPS.
2. Tarjoa Strict-Transport-Security: max-age=0.
3. Pidä se käytössä riittävän pitkään, jotta palaavat käyttäjät saavat sen.
4. Poista tai korvaa otsake, kun häiriö on ratkaistu.

Jos verkkotunnus on preloaded, max-age=0-arvon tarjoaminen ei riitä uusille selainprofiileille. Sinun täytyy myös pyytää poistoa preload-listalta ja odottaa, että muutos toimitetaan selainpäivitysten kautta.

Testauksen tarkistuslista ennen julkaisua

Käytä tätä tarkistuslistaa ennen max-age-arvon kasvattamista tai includeSubDomains-direktiivin lisäämistä:

• Kanoninen HTTPS-URL palauttaa kelvollisen varmenteen.
• HTTP ohjautuu HTTPS:ään.
• HSTS-otsakkeita on vain yksi.
• Otsake näkyy uudelleenohjauksissa ja virhevastauksissa, kun se on tarkoituksenmukaista.
• Kaikilla julkisilla aliverkkotunnuksilla on kelvollinen HTTPS.
• Varmenteiden uusimista valvotaan.
• Mikään kriittinen sisäinen järjestelmä ei riipu HTTP:stä saman pääverkkotunnuksen alla.
• Preloadista on keskusteltu nimenomaisesti, eikä sitä ole lisätty tottumuksesta.

Lighthouse voi joissakin yhteyksissä merkitä puuttuvat tai heikot tietoturvaotsakkeet, mutta sen ei pitäisi olla ainoa varmistusmenetelmäsi. Jos käytät sitä osana laajempaa tarkistusta, lue löydökset signaaleina etkä tuomioina; sama ajattelutapa pätee, kun luet Lighthouse-raporttia panikoimatta.

<!-- tool-cta:start -->

💡 Kokeile tätä: Tarkista ennen jokaista HSTS-muutosta ja sen jälkeen Strict-Transport-Security-vastaus Get Headers-työkalulla varmistaaksesi, että max-age, includeSubDomains ja preload ovat odotustesi mukaiset.

<!-- tool-cta:end -->

HSTS:n yksityisyysperustelu

HSTS kuvataan usein tietoturvaotsakkeena, ja sitä se on. Sillä on myös yksityisyyshyöty: se vähentää mahdollisuutta, että käyttäjän ensimmäinen pyyntö vuotaa tavallisen HTTP:n yli epäluotettavassa verkossa.

Sillä on merkitystä lentokenttien Wi-Fi-verkoissa, hotelliverkoissa, yritysten vierasverkoissa ja kaikkialla, missä käyttäjän liikennettä voidaan tarkkailla tai muokata. Tavallinen HTTP-pyyntö voi paljastaa isäntänimen, polun, evästeet ilman Secure-lippua ja muita pyynnön yksityiskohtia. HTTPS ei ole taikuutta, mutta sen johdonmukainen pakottaminen poistaa kokonaisen luokan vältettävissä olevia vuotoja.

Parhaat HSTS-käyttöönotot ovat tylsiä. Ne otetaan käyttöön hitaasti, niitä tukevat luotettavat varmenteet, ja ne ovat niin arkisia, ettei kukaan huomaa. Juuri sitä haluat otsakkeelta, jonka vikatila voi olla dramaattinen.