HTTP:n alasajo ja yhdistetyn sisällön riskit

HTTP Strict Transport Security (HSTS) -otsake ohjeistaa selaimia muodostamaan yhteyden sivustoon vain HTTPS:n kautta määritetyn ajanjakson ajan. Kun selain on vastaanottanut otsakkeen, se kieltäytyy HTTP-yhteyksistä ja päivittää http://-URL-osoitteet automaattisesti muotoon https://.

Tyypillinen HSTS-otsake on: "Strict-Transport-Security: max-age=31536000; includeSubDomains; preload". max-age ilmoitetaan sekunteina (31536000 = 1 vuosi). Kun asetus on tallennettu välimuistiin, selain pakottaa HTTPS:n käyttöön vuoden ajan ilman palvelimen osallistumista.

max-age-parametri määrittää sekunteina, kuinka kauan selain pakottaa käyttämään vain HTTPS-yhteyksiä. Tuotantosivustoille suositellaan vähintään vuoden arvoa (31536000).

includeSubDomains-direktiivi laajentaa HSTS:n koskemaan kaikkia alitoimialueita. Tämä estää hyökkäykset, joissa hyökkääjä palauttaa alitoimialueen yhteyden HTTP:hen ja käyttää sitä ilman Secure-lippua päätoimialueella asetettujen evästeiden varastamiseen.

Selainten mukana toimitetaan kiinteästi määritetty luettelo toimialueista, joissa käytetään aina vain HTTPS:ää, myös ensimmäisellä käyntikerralla. Luetteloa ylläpidetään osoitteessa hstspreload.org, ja se sisältää tuhansia merkittäviä verkkosivustoja.

Esilataus poistaa ensimmäisen käyntikerran haavoittuvuuden: ilman esilatausta ensimmäinen kävijä voitaisiin siepata ennen HSTS-otsakkeen vastaanottamista. Esiladatut sivustot käyttävät vain HTTPS:ää jo ensimmäisestä pyynnöstä lähtien HSTS-välimuistin tilasta riippumatta.

SSL-strippaus, jonka Moxie Marlinspike esitteli Black Hat 2009 -tapahtumassa, on MITM-hyökkäys, jossa HTTPS-yhteys palautetaan HTTP-yhteydeksi. Hyökkääjä sieppaa käyttäjän ensimmäisen HTTP-pyynnön, tekee HTTPS-pyynnöt oikealle palvelimelle käyttäjän puolesta ja välittää sisällön HTTP:n kautta käyttäjälle.

Uhri näkee sisällön normaalisti, mutta yhteys käyttää HTTP:tä. Kaikki syötetyt tunnistetiedot päätyvät hyökkääjälle. Ennen HSTS:ää hyökkäys oli erittäin tehokas, koska käyttäjät eivät huomanneet puuttuvaa lukkokuvaketta.

HSTS estää SSL-strippauksen, koska selain kieltäytyy muodostamasta HTTP-yhteyksiä HSTS:n piiriin kuuluville toimialueille. Vaikka hyökkääjä yrittäisi tarjota sivua HTTP:n kautta, selain yksinkertaisesti kieltäytyy yhteydestä ja näyttää virheen.

Selaimen HSTS-valvonta tapahtuu ennen verkkopyyntöä, joten hyökkääjä ei voi puuttua siihen. Ainoa jäljelle jäävä haavoittuvuus on ensimmäinen käyntikerta ennen HSTS:n vastaanottamista, ja esilataus poistaa sen.

Sekasisältöä syntyy, kun HTTPS-sivu lataa resursseja HTTP:n kautta. Passiiviseen sekasisältöön kuuluvat HTTP:n kautta ladatut kuvat, äänet ja videot. Ne eivät voi suoraan muokata sivua, mutta ne voivat paljastaa käyttäjää koskevia tietoja HTTP-otsakkeiden avulla ja mahdollistaa seurannan.

Aktiiviseen sekasisältöön kuuluvat HTTP:n kautta ladatut komentosarjat, tyylisivut, iframe-kehykset ja XMLHttpRequests-pyynnöt. HTTP:n kautta ladattu komentosarja voi vaarantaa HTTPS-sivun tietoturvan täysin, koska sillä on täydet oikeudet DOM-rakenteeseen ja se voi lukea evästeitä sekä lomaketietoja.

Nykyaikaiset selaimet estävät aktiivisen sekasisällön (HTTP:n kautta ladatut komentosarjat, tyylisivut ja iframe-kehykset) oletusarvoisesti, kun ympäröivä sivu käyttää HTTPS:ää. Konsoliin näytetään virhe, eikä resurssia ladata.

Chrome 81 -versiosta (2020) lähtien selaimet ovat alkaneet päivittää passiivisen sekasisällön automaattisesti HTTPS:ään. Jos HTTPS-versio on olemassa, se ladataan. Muussa tapauksessa resurssi estetään.

Selaimen kehittäjäkonsoli näyttää sekasisältöä koskevat varoitukset ja virheet. Avatkaa Chromessa DevTools, siirtykää Console-välilehdelle ja suodattakaa tulokset hakusanalla "Mixed Content". Jokaisen estetyn resurssin yhteydessä näytetään päivitettävä suojaamaton URL-osoite.

DevToolsin Security-paneeli näyttää kattavan tietoturvayhteenvedon: varmenteen tiedot, yhteyden tiedot ja luettelon kaikista sivun suojaamattomista resursseista.

Content Security Policy (CSP) -direktiivi "upgrade-insecure-requests" ohjeistaa selaimia päivittämään kaikki sivulta lähtevät HTTP-pyynnöt automaattisesti HTTPS-pyynnöiksi. Tämä käsittelee vanhan sisällön, jossa on kiinteästi määritettyjä HTTP-URL-osoitteita.

Toisin kuin sekasisällön estäminen, upgrade-insecure-requests yrittää hakea ensin HTTPS-version. Se on hyödyllinen siirryttäessä HTTP:stä HTTPS:ään silloin, kun kaikkien vanhan sisällön upotettujen URL-osoitteiden päivittäminen olisi epäkäytännöllistä.

Ilman HTTPS:ää internet-palveluntarjoajat voivat lisätä sisältöä HTTP-vastauksiin. Useita internet-palveluntarjoajia on jäänyt kiinni mainosten lisäämisestä verkkosivuille, joilla ei alun perin ollut mainoksia, seurantapikselien lisäämisestä tai varoitussivujen lisäämisestä, kun käyttäjät lähestyvät datakattoaan.

Tällainen sisällön lisääminen on mahdotonta HTTPS-sivuilla, koska vastaus todennetaan ja salataan. Kaikki muutokset aiheuttaisivat TLS:n MAC-tarkistuksen epäonnistumisen, jolloin yhteysvirhe estäisi muokatun sisällön tarjoamisen.

Ennen kuin selain on nähnyt toimialueen HSTS-otsakkeen, ensimmäinen HTTP:n kautta tehtävä käynti on haavoittuva. Hyökkääjä voi siepata tämän ensimmäisen pyynnön ja toteuttaa SSL-strippauksen ilman selaimen varoituksia.

Tämä "luota ensimmäisellä käyttökerralla" -haavoittuvuus on syy HSTS-esilatausluettelon olemassaoloon. Sivuston lisääminen esilatausluetteloon varmistaa, että selaimet pakottavat toimialueen käyttämään HTTPS:ää jo ensimmäisestä pyynnöstä lähtien ja sulkevat ensimmäisen käynnin aikaikkunan kokonaan.

HSTS ohjeistaa selaimia pakottamaan toimialueen yhteydet käyttämään vain HTTPS:ää määritetyn ajan. Esilatausluettelo laajentaa suojan myös ensimmäisiin käyntikertoihin määrittämällä HSTS-käytännöt kiinteästi selaimiin.

SSL-strippaus (Moxie Marlinspike, 2009) palauttaa HTTPS-yhteyden HTTP-yhteydeksi, mutta HSTS estää sen. Selaimet estävät aktiivisen sekasisällön eli HTTP:n kautta ladatut komentosarjat HTTPS-sivuilla. upgrade-insecure-requests-CSP-direktiivi automatisoi vanhan sisällön siirtämisen HTTP:stä HTTPS:ään.