Robert Heaton

HTTPS on yksinkertaisesti tavallinen HTTP-protokolla, joka on kuorrutettu runsaalla kerroksella herkullista SSL/TLS-salausta. Ellei jokin mene kauheasti pieleen (ja se voi mennä), se estää surullisenkuuluisan Eevan kaltaisia henkilöitä katsomasta tai muokkaamasta pyyntöjä, jotka muodostavat selauskokemuksesi; se pitää salasanasi, viestintä- ja luottokorttitietosi turvassa tietokoneesi ja niiden palvelimien välisessä langassa, joille haluat lähettää nämä tiedot. Vaikka pieni vihreä riippulukko ja kirjaimet ”https” osoitepalkissasi eivät tarkoita, etteikö sekä sinulla että katsomallasi verkkosivustolla olisi vielä runsaasti köyttä, jonka avulla voisitte hirttäytyä muualle, ne ainakin auttavat sinua kommunikoimaan turvallisesti samalla kun teet niin.

Mikä on HTTPS ja mitä se tekee?

HTTPS käyttää hyvin tunnettua ja ymmärrettävää HTTP-protokollaa, ja sen päälle kerrokseksi laitetaan yksinkertaisesti SSL-/TLS-salauskerros (jatkossa pelkkä ”SSL”). Palvelimet ja asiakkaat puhuvat edelleen täsmälleen samaa HTTP:tä toisilleen, mutta suojatun SSL-yhteyden kautta, joka salaa ja purkaa niiden pyynnöt ja vastaukset. SSL-kerroksella on kaksi päätarkoitusta:

• Varmennetaan, että puhut suoraan sille palvelimelle, jolle luulet puhuvasi
• Varmennetaan, että vain palvelin voi lukea sen, mitä lähetät sille, ja vain sinä voit lukea sen, mitä se lähettää takaisin

Todella, todella nokkela osa on se, että kuka tahansa voi salakuunnella jokaisen viestin, jonka vaihdat palvelimen kanssa, mukaan lukien ne viestit, joissa sovitte käytettävästä avaimesta ja salausstrategiasta, eikä silti pysty lukemaan yhtään varsinaista lähettämääsi tietoa.

Miten SSL-yhteys muodostetaan

Asiakkaan ja palvelimen välinen SSL-yhteys muodostetaan kädenpuristuksella, jonka tavoitteet ovat:

• Vakuuttaa asiakas siitä, että se puhuu oikealle palvelimelle (ja mahdollisesti päinvastoin)
• Se, että osapuolet ovat sopineet ”salauspaketin”, joka sisältää sen, mitä salausalgoritmia ne käyttävät tietojen vaihtoon
• Osapuolet ovat sopineet tarvittavista avaimista tätä algoritmia varten

Kun yhteys on muodostettu, molemmat osapuolet voivat käyttää sovittua algoritmia ja avaimia lähettääkseen viestejä toisilleen turvallisesti. Jaetaan kättely kolmeen päävaiheeseen: Hello, Certificate Exchange ja Key Exchange.

1. Hello – Kättely alkaa asiakkaan lähettämällä ClientHello-sanomalla. Tämä sisältää kaikki tiedot, joita palvelin tarvitsee voidakseen muodostaa yhteyden asiakkaaseen SSL:n kautta, mukaan lukien eri salausyhdistelmät ja sen tukema SSL:n maksimiversio. Palvelin vastaa ServerHello-sanomalla, joka sisältää samankaltaisia asiakkaan tarvitsemia tietoja, mukaan lukien asiakkaan mieltymyksiin perustuva päätös siitä, mitä salauspakettia ja SSL-versiota käytetään.

2. Sertifikaattien vaihto – Nyt kun yhteys on luotu, palvelimen on todistettava identiteettinsä asiakkaalle. Tämä onnistuu sen SSL-sertifikaatin avulla, joka on vähän kuin sen passi. SSL-varmenne sisältää erilaisia tietoja, kuten omistajan nimen, omaisuuden (esim. verkkotunnuksen), johon varmenne on liitetty, varmenteen julkisen avaimen, digitaalisen allekirjoituksen ja tiedot varmenteen voimassaoloajoista. Asiakas tarkistaa, että se joko luottaa epäsuorasti varmenteeseen tai että jokin useista varmentajista (Certificate Authorities, CA), joihin se myös epäsuorasti luottaa, on varmentanut sen ja luottaa siihen. Tästä kerrotaan pian lisää. Huomaa, että palvelin voi myös vaatia varmenteen todistamaan asiakkaan henkilöllisyyden, mutta näin tapahtuu yleensä vain hyvin arkaluonteisissa sovelluksissa.

3. Salausavainten vaihto – Asiakkaan ja palvelimen vaihtamien varsinaisten sanomatietojen salaus tehdään symmetrisellä algoritmilla, jonka tarkasta luonteesta sovittiin jo Hello-vaiheessa. Symmetrinen algoritmi käyttää yhtä avainta sekä salaukseen että salauksen purkamiseen, toisin kuin epäsymmetriset algoritmit, jotka vaativat julkisen/yksityisen avainparin. Molempien osapuolten on sovittava tästä yhdestä symmetrisestä avaimesta, mikä tapahtuu turvallisesti käyttämällä epäsymmetristä salausta ja palvelimen julkisia/yksityisiä avaimia.

Asiakas luo satunnaisen avaimen, jota käytetään symmetrisessä pääalgoritmissa. Se salaa sen käyttäen algoritmia, josta sovittiin myös Hello-vaiheessa, ja palvelimen julkista avainta (joka löytyy sen SSL-varmenteesta). Se lähettää tämän salatun avaimen palvelimelle, jossa se puretaan palvelimen yksityisellä avaimella, ja kättelyn mielenkiintoiset osat ovat valmiit. Osapuolet ovat riittävän tyytyväisiä siihen, että he puhuvat oikealle henkilölle, ja ovat salaa sopineet avaimesta, jolla ne salaavat symmetrisesti tiedot, jotka ne aikovat lähettää toisilleen. HTTP-pyynnöt ja -vastaukset voidaan nyt lähettää muodostamalla selväkielinen viesti, joka sitten salataan ja lähetetään. Toinen osapuoli on ainoa, joka osaa purkaa tämän viestin salauksen, joten Man In The Middle -hyökkääjät eivät pysty lukemaan tai muuttamaan sieppaamiaan pyyntöjä.

Varmenteet

Alkeellisimmillaan SSL-varmenne on pelkkä tekstitiedosto, ja kuka tahansa, jolla on tekstieditori, voi luoda sellaisen. Voit itse asiassa triviaalisti luoda varmenteen, jossa väität olevasi Google Inc. ja hallitsevasi verkkotunnusta gmail.com. Jos tämä olisi koko tarina, SSL olisi pelkkä vitsi; henkilöllisyyden todentaminen koostuisi lähinnä siitä, että asiakas kysyy palvelimelta: ”Oletko Google?”, palvelin vastaa: ”Joo, aivan, tässä on paperi, johon on kirjoitettu ’Olen Google'”, ja asiakas sanoo: ”Okei, hienoa, tässä ovat kaikki tietoni.” Taika, joka estää tämän farssin, on digitaalisessa allekirjoituksessa, jonka avulla osapuoli voi varmistaa, että toisen osapuolen paperi on todella laillinen.

On kaksi järkevää syytä, miksi voit luottaa varmenteeseen:

• Jos se on listalla varmenteista, joihin luotat implisiittisesti
• Jos se pystyy todistamaan, että jonkun edellä mainitussa listassa olevan varmenteen rekisterinpitäjä luottaa siihen

Ensimmäinen kriteeri on helppo tarkistaa. Selaimessasi on esiasennettu luettelo varmenneviranomaisten (Certificate Authorities, CA) luotettavista SSL-varmenteista, joita voit tarkastella, lisätä ja poistaa. Näitä varmenteita valvoo keskitetty ryhmä (teoriassa ja yleensä myös käytännössä) erittäin turvallisia, luotettavia ja luotettavia organisaatioita, kuten Symantec, Comodo ja GoDaddy. Jos palvelin esittää varmenteen tästä listasta, tiedät, että voit luottaa siihen.

Toinen kriteeri on paljon vaikeampi. Palvelimen on helppo sanoa, että ”joo, nimeni on Microsoft, luotat Symanteciin ja he luottavat minuun täysin, joten kaikki on hyvin”. Jokseenkin fiksu asiakas saattaa sitten mennä kysymään Symantecilta: ”Minulla on täällä Microsoft, joka sanoo, että sinä luotat heihin, pitääkö tämä paikkansa?”.” Mutta vaikka Symantec sanoisi ”jep, me tunnemme heidät, Microsoft on laillinen”, et silti tiedä, onko palvelin, joka väittää olevansa Microsoft, todella Microsoft vai jotain paljon pahempaa. Tässä kohtaa tulevat kuvaan mukaan digitaaliset allekirjoitukset.

3.2 Digitaaliset allekirjoitukset

Kuten jo todettiin, SSL-varmenteisiin liittyy julkinen/yksityinen avainpari. Julkinen avain jaetaan osana sertifikaattia, ja yksityinen avain pidetään uskomattoman turvallisesti vartioituna. Tätä epäsymmetristä avainparia käytetään SSL-kättelyssä vaihtamaan molemmille osapuolille toinen avain tietojen symmetristä salaamista ja purkamista varten. Asiakas käyttää palvelimen julkista avainta symmetrisen avaimen salaamiseen ja lähettää sen turvallisesti palvelimelle, ja palvelin käyttää yksityistä avaintaan salauksen purkamiseen. Kuka tahansa voi salata julkisella avaimella, mutta vain palvelin voi purkaa salauksen yksityisellä avaimella.

Digitaaliseen allekirjoitukseen pätee päinvastoin. Toinen viranomainen voi ”allekirjoittaa” varmenteen, jolloin viranomainen käytännössä sanoo: ”Olemme varmistaneet, että tämän varmenteen rekisterinpitäjä hallitsee myös varmenteessa mainittua omaisuutta (verkkotunnusta)”. Tässä tapauksessa viranomainen käyttää yksityistä avaintaan (yleisesti ottaen) varmenteen sisällön salaamiseen, ja tämä salattu teksti liitetään varmenteeseen sen digitaalisena allekirjoituksena. Kuka tahansa voi purkaa allekirjoituksen viranomaisen julkisella avaimella ja tarkistaa, että tuloksena on odotettu purettu arvo. Mutta vain viranomainen voi salata sisällön yksityisellä avaimella, joten vain viranomainen voi ylipäätään luoda kelvollisen allekirjoituksen.

Jos siis palvelin tulee ja väittää, että sillä on Symantecin (tai jonkin muun varmentajan) allekirjoittama varmenne Microsoft.com-sivustolle, selaimesi ei tarvitse uskoa sitä. Jos se on laillinen, Symantec on käyttänyt (erittäin salaista) yksityistä avaintaan luodakseen palvelimen SSL-varmenteen digitaalisen allekirjoituksen, joten selaimesi voi käyttää sen (erittäin julkista) julkista avainta tarkistaakseen, että allekirjoitus on voimassa. Symantec on ryhtynyt toimenpiteisiin varmistaakseen, että organisaatio, jonka puolesta se allekirjoittaa, todella omistaa Microsoft.com-sivuston, joten koska asiakkaasi luottaa Symanteciin, se voi olla varma, että se todella puhuu Microsoft Inc:n kanssa.

3.3 Itsesigneeraus

Huomaa, että kaikki päävarmentajan varmenteet ovat itsesigneerattuja, mikä tarkoittaa, että digitaalinen allekirjoitus luodaan varmenteen omaa yksityistä avainta käyttäen. Juurivarmentajan varmenteessa ei ole sinänsä mitään erityistä – voit halutessasi luoda oman itse allekirjoitetun varmenteen ja käyttää sitä muiden varmenteiden allekirjoittamiseen. Mutta koska satunnaista varmentajaasi ei ole ladattu valmiiksi CA:na mihinkään selaimiin, mikään niistä ei luota siihen, että allekirjoitat omia tai muita varmenteita. Käytännössä sanot: ”Joo, olen täysin Microsoft, tässä on virallinen identiteettivarmenne, jonka olen itse myöntänyt ja allekirjoittanut”, ja kaikki kunnolla toimivat selaimet näyttävät hyvin pelottavan virheilmoituksen vastauksena epäilyttäviin tunnistetietoihisi.

Tämä asettaa valtavan taakan kaikille selainten ja käyttöjärjestelmien julkaisijoille, jotta ne luottaisivat vain nuhteettoman puhtaisiin pääkäyttäjävarmennevarmennevarmennevarmennevarmennevarmennevarmennevarmennevarmennevarmennevarmennevarmennevarmennevarmennevarmennevarmennevarmennevarmennevarmennevarmennevarmennevirastoihin. Tämä ei ole helppo tehtävä.

3.4 Mihin luotat?

On mielenkiintoista huomata, että asiakkaasi ei teknisesti yritä tarkistaa, pitäisikö sen luottaa varmenteen lähettäneeseen osapuoleen, vaan pitäisikö sen luottaa varmenteen sisältämään julkiseen avaimeen. SSL-varmenteet ovat täysin avoimia ja julkisia, joten kuka tahansa hyökkääjä voisi napata Microsoftin varmenteen, siepata asiakkaan Microsoft.com-pyynnön ja esittää sille laillisen varmenteen. Asiakas hyväksyisi tämän ja aloittaisi tyytyväisenä kättelyn. Kun asiakas kuitenkin salaa avaimen, jota käytetään varsinaiseen tietojen salaukseen, se tekee sen oikean Microsoftin julkisen avaimen avulla, joka on peräisin tästä oikeasta varmenteesta. Koska hyökkääjällä ei ole Microsoftin yksityistä avainta salauksen purkamiseksi, hän on nyt jumissa. Vaikka kättely saataisiinkin päätökseen, he eivät silti pysty purkamaan avainta, eivätkä näin ollen pysty purkamaan mitään asiakkaan heille lähettämiä tietoja. Järjestys säilyy niin kauan kuin hyökkääjä ei hallitse luotetun varmenteen yksityistä avainta. Jos asiakas jotenkin huijataan luottamaan varmenteeseen ja julkiseen avaimeen, jonka yksityistä avainta hyökkääjä hallitsee, ongelmat alkavat.

4.1 Voiko kahvila valvoa HTTPS-liikennettäni verkossaan?

Ei. Julkisen avaimen salauksen taika tarkoittaa sitä, että hyökkääjä voi tarkkailla jokaista tavua asiakkaan ja palvelimen välillä vaihdettua dataa, eikä hänellä silti ole aavistustakaan siitä, mitä sanotte toisillenne sen lisäksi, että hänellä on suunnilleen tietoa siitä, kuinka paljon dataa vaihdatte. Normaali HTTP-liikenteesi on kuitenkin edelleen hyvin haavoittuvaista turvattomassa wi-fi-verkossa, ja huolimaton verkkosivusto voi joutua minkä tahansa kiertotien uhriksi, joka jotenkin huijaa sinut lähettämään HTTPS-liikennettä joko tavallisen HTTP:n kautta tai kokonaan väärään paikkaan. Vaikka esimerkiksi kirjautumislomake lähettäisi käyttäjätunnus/salasana-yhdistelmän HTTPS:n kautta, jos itse lomake ladataan turvattomasti HTTP:n kautta, hyökkääjä voi siepata lomakkeen HTML:n matkalla koneellesi ja muokata sitä lähettämään kirjautumistiedot omaan päätepisteeseensä.

4.2 Voiko yritykseni valvoa HTTPS-liikennettäni verkonsa välityksellä?

Jos käytät myös yrityksesi valvomaa konetta, niin kyllä. Muista, että jokaisen luottamusketjun juuressa on implisiittisesti luotettu CA, ja että luettelo näistä auktoriteeteista on tallennettu selaimeesi. Yrityksesi voi käyttää koneesi käyttöoikeuttaan lisätä oman itse allekirjoitetun varmenteensa tähän varmentajien luetteloon. Sen jälkeen se voisi siepata kaikki HTTPS-pyyntönne ja esittää varmenteita, jotka väittävät edustavansa asianmukaista verkkosivustoa ja jotka on allekirjoittanut sen väärennetty varmenneviranomainen ja joihin selaimenne siksi luottaa kiistatta. Koska salaisit kaikki HTTPS-pyyntönne käyttäen heidän epäilyttävän varmenteensa julkista avainta, he voisivat käyttää vastaavaa yksityistä avainta purkaakseen ja tutkiakseen (jopa muuttaakseen) pyyntönne ja lähettäessään sen sitten aiottuun paikkaan. Todennäköisesti he eivät tee niin. Mutta he voisivat.

Sattumoisin tällä tavoin käytetään myös välityspalvelinta tarkastamaan ja muokkaamaan iPhonen sovelluksen tekemiä, muuten saavuttamattomissa olevia HTTPS-pyyntöjä.

4.3 Mitä sitten tapahtui Lavabitin ja FBI:n kanssa?

Lavabit oli Edward Snowdenin superturvallinen sähköpostipalveluntarjoaja NSA-vuotojen mielettömyyksien aikana vuonna 2013. Kuten olemme nähneet, mikään tavallinen hakkerointi ei antanut FBI:n nähdä mitään tietoja, jotka olivat matkalla Lavabitin ja sen asiakkaiden välillä. Ilman Lavabitin SSL-sertifikaatin yksityistä avainta virasto oli pulassa. Avulias yhdysvaltalainen tuomari kuitenkin kertoi Lavabitin perustajalle Ladar Levisonille, että hänen oli luovutettava tämä avain, jolloin FBI sai käytännössä vapaat kädet nuuskia liikennettä sydämensä kyllyydestä. Levison yritti urheasti viivytellä luovuttamalla 2 560 merkkiä sisältävän avaimen 11 nelipistekirjoituksella kirjoitetulla paperisivulla, mutta hän sai määräyksen, jossa häntä vaadittiin luovuttamaan avain käyttökelpoisessa muodossa tai maksamaan 5 000 dollarin päiväsakko, kunnes hän luovuttaa avaimen.

Kun Levison noudatti määräystä, Lavabitin varmentaja GoDaddy peruutti varmenteen katsottuaan (aivan oikein), että se oli vaarantunut. Tämä lisäsi Lavabitin varmenteen Certificate Revocation List (CRL) -luetteloon, joka on luettelo hylätyistä varmenteista, joihin asiakkaiden ei pitäisi enää luottaa turvallisen yhteyden tarjoamiseksi. Pilaantuneet, itse allekirjoitetut tai muuten epäluotettavat varmenteet saavat selaimet näyttämään suuren punaisen virheilmoituksen ja joko estämään tai suorastaan kieltämään käyttäjän jatkotoimet. Valitettavasti selaimet luottavat rikkinäiseen varmenteeseen niin kauan, kunnes ne vetävät uusimmat päivitykset CRL:ään, mikä prosessi on ilmeisen epätäydellinen käytännössä.

Johtopäätös

HTTPS ei ole murtumaton, ja SSL-protokollan on kehityttävä jatkuvasti, kun uusia hyökkäyksiä sitä vastaan löydetään ja torjutaan. Se on kuitenkin edelleen vaikuttavan vankka tapa välittää salaista tietoa välittämättä siitä, kuka viestejäsi näkee. On tietenkin monia yksityiskohtia, joita ei ole mainittu tässä, kuten kättelyviestien tarkka muoto ja järjestys, lyhennetyt kättelyt, joiden avulla voidaan poimia viimeisimmät istunnot ilman, että avaimia ja salausyhdistelmiä tarvitsee neuvotella uudelleen, ja lukuisat eri salausvaihtoehdot, jotka ovat käytettävissä kussakin vaiheessa. Tärkeintä on muistaa, että vaikka HTTPS suojaa dataa matkalla määränpäähänsä, se ei millään tavoin suojaa sinua (käyttäjänä tai kehittäjänä) XSS:ltä, tietokantavuodoilta tai muilta sellaisilta asioilta, joita yöllä sattuu ja tapahtuu. Ole iloinen, että se suojaa selustasi, mutta pysy valppaana. Will Smithin kuolemattomien sanojen mukaan: ”Kävele varjossa, liiku hiljaisuudessa, varo maan ulkopuolista väkivaltaa.”

Jos nautit tästä, nautit luultavasti postauksestani, jossa selitän vuoden 2015 FREAK-haavoittuvuuden yksityiskohtia SSL:ssä.