Tämä kirjoitus on osa tietoturvalliset verkkosovellukset -sarjaa. Löydät kaikki sarjan kirjoitukset tästä linkistä.

HTTPS / SSL - akronyymit, joilla on merkitystä

Lokakuussa 2010 Eric Butler julkaisi Firefox -selaimeen laajennoksen nimeltä Firesheep (Wikipedialinkki). Tämä laajennos toi yleiseen tietoisuuteen sen, miten haavoittuvaa salaamaton verkkoliikenne todellisuudessa onkaan. Tämä haavoittuvuus on "sisäänrakennettu" normaaliin verkkoliikenteeseen, eikä sitä oteta yhtään niin vakavasti, kuin ehkä pitäisi.

Firesheep tarjosi käyttäjille mahdollisuuden tarkkailla salaamatonta verkkoliikennettä paikallisverkossa ja kaapata toisen käyttäjän istunnon. Firesheep käyttää nk. "mies keskellä" -hyökkäystä. Tämä hyökkäys on mahdollista suorittaa vaikka silloin, kun kaksi käyttäjää käyttävät samaa langatonta verkkoa esimerkiksi hotellissa, lentokentällä, kauppakeskuksessa, ym. Jos käyttäjä A sitten kirjautuu johonkin sivustoon, joka ei käytä salattua yhteyttä, voi käyttäjä B kaapata hänen istuntonsa nappia painamalla. Käyttäjä B voi siis esimerkiksi lukea ja kirjoittaa viestejä käyttäjän A nimissä. Tai mitä vain muuta, mitä kyseinen verkkopalvelu tarjoaa.

Tämän kaltainen hyökkäys on aina ollut mahdollinen niille, jotka tietävät jotain verkkotekniikasta, mutta Firesheep tarjosi siihen helpon pääsyn kaikille, jotka osaavat asentaa selainlaajennoksen ja klikata painiketta.

Haavoittuvuus toimii siis siten, että kun käyttäjä on kirjautunut ja aloittanut istunnon palvelimella, tuo istunto voidaan kaapata. Aiemmin yritykset ovat kyllä salanneet kirjautumissivuja, joka vaikeuttaa salasanojen ja käyttäjätunnusten vuotamisen, mutta jättäneet muut sivut salaamatta, mahdollistaen näin istunnon kaappaamisen. Nykyään Gmail, Facebook ja Twitter salaavat kaikki sivunsa.

Mitä on HTTPS?

Normaali verkkoliikenne kulkee HTTP:n (HyperText Transfer Protocol) yli. http://www.google.com tarjoaa selaimelle ohjeen siitä, että protokolla on HTTP ja oletusportti on 80. HTTP ei ole yhtään turvallinen, vaan kaikki tieto kulkee luettavassa muodossa. HTTPS puolestaan tarkoittaa HTTP:ta, jossa liikenne salataan SSL:llä.

Hyvin karkeasti kuvattuna HTTPS tarkoittaa sitä, että paketin voi lukea vain tarvittavilla oikeuksilla. Sertifioiva auktoriteeti allekirjoittaa digitaalisesti sertifikaatin, joka todistaa, että sivustosi on validi. Käyttäjän selain tuntee nämä auktoriteetit ja tarkistaa sertifikaatin auktoriteetin pääsertifikaattia vastaan. Näin syntyy salausavain, jota käytetään kummassakin päässä. Näin kaikki liikenne selaimen ja palvelimen välillä on salattua, mutta molemmat päät tietävät, miten tuon salauksen saa purettua.

Mutta liikenne ei jää vain yhden avaimen varaan, muutenhan palvelin voisi purkaa salauksen käyttäjän kaikista tiedoista. SSL käyttää kahta avainta, julkista ja yksityistä. Periaate on, että kuka tahansa saa tietää julkisen avaimen, mutta vain itse tiedämme salaisen avaimemme. Kuitenkin, kun käyttäjä salaa jotain meidän julkisella avaimella ja omalla salaisella avaimellaan, niin me voimme avata sen hänen julkisella avaimella ja meidän salaisella avaimella.

Miksi kaikki liikenne ei ole HTTPS:ää?

Salatulla liikenteellä on haittapuolensa. SSL-sertifikaatti liittyy aina palvelimeen. Tämä hankaloittaa virtuaalipalvelimien sertifiointia, sillä niissä liikenne saapuu ensin fyysiselle palvelimelle, ennen kuin se osataan ohjata palvelimella pyörivään virtuaalipalvelimeen. Fyysisellä palvelimella pyörivien virtuaalipalvelimien omat sertifikaatit vaativat kiertoteitä.

Toinen iso asia on nopeus. HTTPS yhteys vaatii SSL:n yhteysmuodollisuudet ennen kuin yhteys voidaan muodostaa. Tämä tekee koko prosessista hitaamman. Mutta kun yhteysmuodollisuudet on kerran tehty, myöhemmät yhteydet vaativat vain salauksen ja purkamisen, joka ei ole aivan niin hidasta.

Toinen asia on välimuisti. Selain voi tallentaa tietoja välimuistiin HTTPS:n kanssa siinä missä HTTP:nkin, mutta joissain osissa maailmaa Internet palveluntarjoaja saattaa käyttä Proxy-välimuistia pyyntöjen nopeuttamiseksi. Proxy-välimuistia taasen ei voida käyttää HTTPS:n kanssa, sillä tuo Proxypalvelin näkee vain salattua tietoa. Tämä voi olla tai voi olla olematta ongelma, riippuen käyttäjien sijainnista ja yhteyksien laadusta.

Viimeisenä tulee tietysti hinta. Sertifikaatit maksavat rahaa. Perus-sertifikaatti, joka tarjoaa useimmissa selaimissa vain sen pienen lukko-ikonin osoitepalkkiin, maksavat joitain kymppejä. Laajemmat sertifikaatit, jotka tarjoavat useimmissa selaimissa sen vakuuttavan vihreän palkin osoiteriville (ja sen mukana tulevan mielenrauhan) maksavat taas kymmenkertaisesti enemmän. Tietysti yritykselle tämä ei ole mikään este, mutta harrastekoodarilta se saattaa jäädä hankkimatta. Ja joku joskus saattaa käyttää samaa salasanaa harrastekoodarin palvelussa, kuin oikeissakin palveluissa.

Milloin tulisi käyttää SSL:ää?

Aikaisemmin tapana on ollut salata kirjautumissivut ja vaikkapa verkkokauppojen ostoskorisivut. Nämä tuleekin salata, mutta jos jättää salaamisen vain tähän, mahdollistaa "mies keskellä" -hyökkäyksen ja istunnon kaappaamisen. Nykyään trendinä on ollut salata kaikki sivut. Tämä on melko hyvä ohje, mutta tähänkään ei voi sokeasti luottaa. On hyvä käyttää HTTPS:ää kaikilla sivuilla, mutta sitä päätöstä tehdessä pitää olla tietoinen myös yllä esitellyistä haittapuolista.

Jos käsittelet luottokorttinumeroita tai henkilötietoja, sinulla on velvollisuus toteuttaa paras mahdollinen suoja näille tiedoille. Silloin HTTP ei ole edes vaihtoehto.

Koodipuoli lyhyesti

Kuten alussa mainittua, tämä kirjoitus ei käsittele paljoakaan koodauspuolta, mutta muutaman rivin tähänkin saa liitettyä. Kun verkkosovelluksessa liikutaan näkymistä toisiin tai ladataan ulkoisia resursseja, kuten tyylisivuja tai JavaScript -tiedostoja, on tärkeää asettaa näiden polut oikein. Apache ja Nginx voidaan määrittää ohjaamaan kaikki salaamaton porttiin 80 saapuva liikenne automaattisesti eteenpäin salattuun osoitteeseen. HTML dokumentissa olevat polut pitää puolestaan asettaa käsin.

Jos sivusto on staattinen, saatetaan ulkoisiin resursseihin viitata lyhyellä relatiivisella polulla:

<link rel="stylesheet" href="css/style.css">

Mutta verkkosovelluksista puhuttaessa HTML dokumentit ovat usein fragmentoituneita ja koostettuja useista sijainneista. Silloin näihin resursseihin voidaan joutua viittaamaan täydellisellä polulla:

<link rel="stylesheet" href="http://www.ocllo.fi/css/style.css">

Tällöin tulimme kuitenkin määrittäneeksi salatun yhteytemme sisällä salaamattoman yhteyspisteen. Jos haluamme käyttää ulkoista resurssia salatusta ja salaamattomasta yhteydestä, voimme käyttää polkua, joka on absoluuttisen ja relatiivisen välimaastosta:

<link rel="stylesheet" href="//www.ocllo.fi/css/style.css">

Tämä kahden kauttaviivan (//) merkkaustapa parsiutuu joko http:// tai https://, riippuen käyttämästämme yhteystavasta.

Lopuksi

Tämä kirjoitus käsitteli kovin korkealla tasolla HTTPS:n ja SSL:n käyttöä verkkosovelluksissa. Sertifikaatin hankkiminen ja palvelinohjelman asetusten määrittäminen on ihan oma osionsa. Jos haluat syventyä asiaan, kannattaa lukea Apachen dokumentaatio tai Nginx:n wiki asiasta.

Lähteet ja kirjallisuutta

Bulletproof SSL and TLS (Amazon.com), Ivan Ristic

Building secure PHP apps - a practical guide, Ben Edmunds