YLIMÄÄRÄINEN TIETOTURVAKATSAUS 3b/ Varmennejärjestelmän heikkouksista

Transkriptio

1 YLIMÄÄRÄINEN TIETOTURVAKATSAUS 3b/ Varmennejärjestelmän heikkouksista 1

2 CERT-FI:n tietoturvakatsaus 3b/2011 Varmennejärjestelmän heikkouksista Tämä CERT-FI:n ylimääräinen tietoturvakatsaus käsittelee varmennejärjestelmistä löytyneitä heikkouksia ja varmennepalveluiden tarjoajiin kohdistuneita tietoturvaloukkauksia. Katsaus täydentää ja syventää tietoturvakatsauksessa 3/2011 käsiteltyä asiaa. Artikkeli sisältää loppukäyttäjille, tietohallinnoille ja sovelluskehittäjille suunnattuja suositeltavia toimenpiteitä ja menettelyjä, joilla omasta ja sivullisten tietoturvasta on mahdollista varmistua. Varmennejärjestelmän turvallisuus on järkkynyt Useat palvelinvarmenteita myöntävät yritykset ovat joutuneet kuluvan vuoden aikana tietomurtojen uhreiksi tai tietomurtoyritysten kohteiksi. Tunkeutujien haltuun saamia käyttövaltuuksia on käytetty palvelinvarmenteiden tuottamiseen kolmansien osapuolten kuten Googlen nimissä. Petoksella hankittujen varmenteiden käyttötarkoituksesta ei ole varmaa tietoa. Spekulaatioissa on esitetty eräiden valtiollisten turvallisuuselinten sekaantuneen toimintaan. Varmennejärjestelmän teknisiä ja prosessiin liittyviä heikkouksia on kyetty osoittamaan ennenkin. Varmennepalvelujen tarjoajat ovat allekirjoittaneet palvelinvarmenteita ilman, että hakijan todellista identiteettiä ja asemaa on selvitetty. Varmenteiden voimassaolon tarkistaminen ja mitätöinti eivät toimi luotettavasti, mikä aiheuttaa ongelmia varmenteiden avainparin joutuessa ulkopuolisten haltuun. Käyttöjärjestelmät ja sovellukset nojaavat suureen määrään luotetuiksi oletettuja juurivarmentajia, vaikka suurin osa käyttäjistä ei koskaan tarvitse näiden allekirjoittamia varmenteita. Käytäntö on osoittanut, että kaikki varmentajat eivät ole luottamuksen arvoisia. Luottosuhteen peruuttamiseen ei ole olemassa varmoja teknisiä menettelyjä. Kuluvan vuoden tapahtumat ovat nostaneet ongelmat yleisesti nähtäville. Järjestelmän heikkouksia on hyväksikäytetty järjestelmällisesti ja suuren käyttäjämäärän tietoturvallisuus on vaarantunut. Varmenteiden tuoma suoja on nykyisellään epätäydellinen, eikä merkittäviä parannuksia ole odotettavissa ilman koko varmennejärjestelmän perusteellista uusimista. Tässä dokumentissa esitellään julkisuuteen tulleita tietoturvaloukkauksia ja tietoturvauhkia sekä jaetaan neuvoja, joiden avulla käyttäjät, tietohallinnot ja sovelluskehittäjät voivat hyödyntää olemassa olevan varmennejärjestelmän turvaominaisuuksia ympäristöjensä suojaksi. 2

3 Tapaus ComodoHacker Vuonna 2011 on tehty useita onnistuneita tietomurtoja, jotka ovat kohdistuneet varmenteita myöntäviin yrityksiin. Yhteistä tapauksille on, että tekijä on pyrkinyt luomaan käyttöönsä aitoja palvelinvarmenteita. Osassa tapauksia tunkeutuja on onnistunut tavoitteessaan ja kyennyt jopa pitämään toimintansa salassa. Murtojen tekijää ja toimeksiantajaa ei tiedetä. Nimimerkillä ComodoHacker esiintyvä hakkeri on julkisesti ilmoittanut olevansa vastuussa teoista. Nimimerkin takana oleva taho on perustellut tekoaan kertoen toimivansa Iranin hallinnon puolesta arabikevään liikehdintää vastaan. Nimimerkin käyttäjän henkilöllisyydestä tai kansalaisuudesta ei ole tietoa. Ei tiedetä edes sitä, onko nimimerkin takana yksittäinen henkilö vai ryhmä. Ensimmäinen julkisuuteen tullut tietomurto suuntautui Comodo-nimiseen yhdysvaltalaiseen juurivarmentajaan. Yhtiö julkisti tiedotteen, jossa se kertoi alihankkijan lukuun työskennelleen henkilön käyttäjätunnusten joutuneen ulkopuolisen haltuun. Käyttäjätunnusten avulla luotiin yhdeksän palvelinvarmennetta, muun muassa osoitteille ja login.skype.com. Yritys huomasi murron tuntien kuluessa tapahtuneesta ja mitätöi petoksen kautta hankitut varmenteet. Koska pelkkä varmenteiden mitätöinti ei välttämättä estä väärinkäytöksiä, keskeiset ohjelmistovalmistajat kuten Microsoft ja Mozilla julkaisivat tuotteistaan nopeutetulla aikataululla päivitysversiot, joilla eiluotettujen varmenteiden käyttö estettiin. Kesäkuun 2011 puolivälissä yritettiin tietomurtoa israelilaiseen StartSSLvarmentajaan. Hyökkääjä pyrki saamaan varmentajan myöntämään varmenteita muiden omistamille palveluille kuten muissakin hyökkäyksissä. StartSSL:n mukaan yritys kuitenkin epäonnistui. Elokuun lopussa paljastui, että alankomaalaiseen DigiNotar-yritykseen tehdyssä tietomurrossa oli onnistuttu luomaan aidolta näyttäviä varmenteita kaikkiin Googlen palveluihin. Vyyhti lähti purkautumaan 28. elokuuta, kun iranilainen käyttäjä tiedusteli tukifoorumille kirjoittamassaan vikakuvauksessa Chrome-selaimen outoa käyttäytymistä. Osoittautui, että iranilainen Pars Online -operaattori ohjasi Googlen palvelimille suuntautuneen liikenteen välittäjäpalvelimille, joissa oli aidolta näyttävät DigiNotarin myöntämät palvelinvarmenteet. Tapaus paljastui, koska Googlen Chrome-selain on ohjelmoitu hälyttämään, mikäli palvelinvarmenne on jonkun muun kuin Googlen ennaltamäärittelemän varmentajan allekirjoittama. DigiNotar ei kuulunut Googlen käyttämien varmentajien listalle. DigiNotarin järjestelmät olivat allekirjoittaneet varmenteen jo , joten tietomurto oli tapahtunut vähintään puolitoista kuukautta aiemmin. DigiNotar myönsi tapahtuneen vasta julkisen paineen edessä. Myöhemmin ilmeni, että yhtiö oli jopa aktiivisesti yrittänyt peitellä tapahtunutta. Alankomaiden hallituksen määräämä turvallisuuskartoitus paljasti, että varmentajan tietoturvakäytännöt olivat olleet vakavasti puutteellisia. Epäselväksi on jäänyt, miten DigiNotarin oli onnistunut aiemmin erehdyttää tietojärjestelmätarkastajia. DigiNotar oli päätynyt selainvalmistajien luottamien varmentajien listalle sen läpäistyä tunnetun auditointeja tekevän konsulttiyrityksen auditoinnin. Maan hallitus on sittemmin ottanut haltuunsa DigiNotarin varmennetoiminnan ja peruuttanut sen varmenteet. DigiNotarin tammikuussa 2011 ostanut Yhdysvaltalainen Vasco haki yhtiön konkurssiin vajaa kuukausi tietomurtojen paljastumisen jälkeen. Kuten Comodon tapauksessa myös DigiNotarin varmenteiden mitätöiminen edellytti ohjelmistovalmistajien reagoimista. Juurivarmentajien mitätöimiseen ei ole varsinaista menettelyä itse varmennejärjestelmän puitteissa. GlobalSign-varmentajan tietomurtoepäily tuli ilmi , kun edelliset murrot suorittanut nimimerkki ComodoHtacker kehuskeli avoimesti asialla. GlobalSign- 3

4 varmenteiden myöntäminen keskeytettiin hetkeksi. Tutkimusten tuloksena ilmeni, että vain yrityksen www-palvelimille oli onnistuttu murtautumaan. Varmenteiden myöntäminen aloitettiin uudelleen muutamia päiviä kestäneiden selvitysten jälkeen Vanhempia tapauksia Jo aiemmin varmennejärjestelmien prosessien heikkouksia on käytetty hyväksi identiteettihuijauksissa. Esimerkiksi vuonna 2008 tietoturvatutkija sai hankittua Live.com-varmenteita Thawtelta. Uudempia tapauksia ComodoHacker-tapauksen jälkeen on julkistettu kaksi uutta varmentajiin liittyvää tietoturvaongelmaa paljastui, että Entrustin alihankkija DigiCert Malaysia oli myöntänyt 22 varmennetta, joissa oli käytetty turvattomiksi katsottuja 512- bitin pituisia avaimia. Varmenteissa ei ollut tietoja varmenteen mitätöintipalvelusta eikä käyttötarkoituksesta. Varmenteiden käyttämisestä petollisesta toiminnassa tai siitä, että varmenteet olisi hankittu petoksella, ei ole näyttöä. DigiCert Malaysian varmenteet on poistettu selainten juurivarmennelistoilta. Lisähämmennystä on aiheuttanut se, että selainten juurivarmennelistoilla on samanniminen merkittävä varmenteiden myyjä, joka toimii Yhdysvalloissa. Comodon tapauksessa. Päivitykset saatiin tarjolle 2-8 päivää tietomurtojen julkitulon jälkeen. Vaikka varsinaisia mekanismeja juurivarmenteiden mitätöimiseen ei olekaan olemassa, tilannetta voidaan korjata julkaisemalla ohjelmistopäivityksiä, joissa poistetaan epäluotettavat varmenteet. Ohjelmistopäivityksissä voi kuitenkin olla merkittäviä viipeitä sekä päivitysten julkaisussa että niiden asentamisessa järjestelmiin. Käytännössä hyökkääjä ehtii käyttää hyväksi käsiinsä saamiaan valheellisia varmenteita pitkäänkin. Varmennejärjestelmän riskit olivat laajalti tiedossa tietoturvayhteisössä jo ennen Comodon tapausta. Järjestelmälle ei ole kuitenkaan ollut olemassa käytännöllisiä vaihtoehtoja. Kuten monen muunkin tekniikan, X.509-varmenteiden ja SSL/TLS (Secure Sockets Layer, uudempi nimitys Transport Layer Security) -protokollan käyttö on laajentunut paljon siitä, mitä standardeja kirjoitettaessa osattiin kuvitella. Protokollia on otettu käyttöön täysin monissa uusissa sovelluksissa. Nykyisin merkittäviä uhkia ei ole riittävästi otettu huomioon suunnittelussa. KPN-operaattorin varmennepalvelu lopetti väliaikaisesti varmenteiden myynnin , kun auditoinnin yhteydessä löydettiin yrityksen www-palvelimelta palvelunestohyökkäystyökalu. Murto on saattanut tapahtua jopa neljä vuottaa aikaisemmin. Tämänhetkisten tietojen mukaan itse varmennejärjestelmiin ei ole päästy käsiksi. Tapausten käynnistämät toimenpiteet Comodon ja DigiNotarin tapauksissa suurin osa selain- ja käyttöjärjestelmävalmistajista julkaisi nopeasti päivitykset, jotka poistivat luottamuksen menettäneet juurivarmenteet. Toiminta DigiNotarin tapauksessa oli jonkin verran nopeampaa kuin 4

5 Miten varmenteita käytetään Varmenteiden avulla käyttäjä voi varmistua siitä, että verkon palvelujen tarjoaja on se taho, joka hän väittääkin olevansa. Varmenteita käytetään myös ohjelmistojen aitouden todistamiseen ja käyttäjien tunnistamiseen. Varmenteita myöntävät varmennepalveluja tarjoavat luotetut varmenteiden myöntäjät (Certificate Authority, CA). Tavallisesti varmenteista muodostetaan hierarkia, jossa ylimmän tason juurivarmenteella allekirjoitetaan alivarmentajien varmenteita, jotka vuorostaan allekirjoittavat myönnettävät varmenteet. Varmennepuun haarat ovat toisistaan erillisiä eikä yhden haaran eli alivarmentajan ja sen alla olevien varmenteiden mitätöinti vaikuta muihin haaroihin. Esimerkiksi www-sivustovarmenteet sisältävät tiedon varmennettavan sivuston verkkotunnuksesta, erinäisiä tietoja tahosta, jolle varmenne on myönnetty, varmenteen varmentajakohtaisen sarjanumeron, voimassaoloajan, tiedon varmentajan varmenteiden sulkulistasta (CRL, Certificate Revocation List) ja varmenteen tilan tarkastamispalvelun (Online Certificate Status Protocol, OCSP) sijainnista, varmenteen myöntäjästä, julkisesta avaimesta ja varmenteen eri käyttötarkoituksista. Varmenteiden käyttökohteena voi yksittäisten verkkotunnusten lisäksi olla muun muassa verkkotunnusten aliverkkoja, sähköpostiosoitteita tai ohjelmistokehittäjiä. Käyttöjärjestelmiin ja joissain tapauksissa myös selaimiin on sisäänrakennettuna luotettujen juurivarmenteiden luettelot. Näiden tahojen myöntämiä sivustokohtaisia varmenteita selain pitää luotettavina. Varmenteita käytetään muun muassa salatuissa SSL/TLS-tietoliikenneyhteyksissä (HTTPS). Jos sivuston varmenne ei ole juurivarmentajien listalla tai tämän avaimella allekirjoitetun varmenteen allekirjoittama, selain varoittaa siitä käyttäjää. Miksi hyökkäykset olivat mahdollisia 5 Jokainen juurivarmenne kelpaa kaikkien sivustojen varmenteiden allekirjoittajaksi: juurivarmenteilla ei ole keskinäistä hierarkiaa. Vaikka palveluntarjoaja olisi hankkinut varmenteen joltakulta tietyltä varmentajalta, minkä tahansa muun luotettavaksi määritellyn varmentajan myöntämä varmenne on oikean varmenteen kanssa samanarvoinen. Haavoittuvimman varmenteiden myöntäjän tietoturva ratkaisee. Varmenteiden muuttumista ei yleisesti seurata selaimissa tai keskitetysti. DigiNotar-tapaus havaittiin vain Googlen Chrome-selaimen toiminnallisuuden avulla, jossa Googlen omien sivustojen varmenteiden myöntäjäksi hyväksyttiin vain tietyt varmentajat. Hierarkian suunnittelussa ei ole otettu huomioon tilanteita, joissa hierarkian ylin taso eli juurivarmentaja muuttuu epäluotettavaksi. Esimerkiksi sulkulistatoiminnallisuutta voi käyttää vain juurivarmentajan allekirjoittamien varmenteiden mitätöimiseen. Käytännössä verkkotunnusten myöntämiseen osallistuu varmenteiden myöntäjien lisäksi rekisteröijiä (Registration Authority, RA) sekä varmenteiden jälleenmyyjiä ja alihankkijoita, mikä monimutkaistaa tilannetta. Ei ole käytössä rajoituksia sille, mitä varmenteita rekisteröijät ja alihankkijat saavat julkaista, vaikka tämä olisi määrittelyjen mukaan mahdollista. Esimerkiksi johdannossa mainitussa Comodon tapauksessa luvattomat varmenteet myönsi juuri alihankkija. Hyökkääjien tavoitteet Väärennetyn varmenteen avulla hyökkääjä voi tehdä man-in-the-middle (MitM)- hyökkäyksen ja kaapata yhteyden palvelun ja sen käyttäjän välillä. Toinen tapa käyttää väärennettyjä varmenteita hyväksi huijauksissa on hyökkääjän tekemän sivuston käyttäminen esimerkiksi käyttäjätunnusten ja salasanojen varastamiseen. Www-palvelujen käyttäjiä kohtaan voisi toteuttaa hyökkäyksen nimipalvelutietoja vääristämällä myös, jos osa sivustosta ladataan kolmannen osapuolen sivustolta. Hyvin suuri osa sivustoista lataa kolmansilta osapuolilta muun muassa mainoksia tai käyttäjien tilastointipalveluja, kuten Googlen tarjoamaa Analytics-palvelua ( MitM-hyökkäyksen suorittaminen vaatii, että joko verkkoinfrastruktuuri tai nimipalvelin on hyökkääjän hallinnassa, tai

6 että hyökkääjä on samassa paikallisverkossa uhrinsa kanssa. Esimerkiksi avoimet WLAN-verkot tarjoavat monia mahdollisuuksia MitM-hyökkäysten toteuttamiseen. Sekä Comodo- että DigiNotar-tapauksissa on esitetty spekulaatioita, että myönnettyjä varmenteita olisi käytetty iranilaisten käyttäjien sähköpostien tarkkailuun. varmennejärjestel- Haasteita missä Tällä hetkellä selainten juurivarmennesäilöissä on vanhaa perua olevia juurivarmenteita, joissa käytetään lyhyitä avaimia ja turvattomia algoritmeja, sekä varmenteita, joilla on hyvin pitkät voimassaoloajat. Luotettujen varmenteiden listoille päässeet juurivarmenteet ja varmentajien salaisia avaimia sisältävät HSM (High Security Module) -turvamoduulit ovat haluttua kauppatavaraa varmentajien kesken, sillä listoille on vaikeaa päästä. Selainvalmistajat ja käyttöjärjestelmien valmistajat ovat määrittäneet tarkat vaatimukset niille varmentajille, jotka haluavat mukaan juurivarmentajien listoille. Vaatimusten mukaan varmenteiden luomiseen käytettyjen järjestelmien turvallisuudesta tulee varmistua muun muassa auditointien avulla. Tämä ei kuitenkaan auttanut DigiNotartapauksessa. Yrityksen turvajärjestelyt olivat murtoon liittyvien tutkimusten yhteydessä julkaistujen raporttien perusteella selkeästi riittämättömät, vaikka yritys oli läpäissyt auditoinnin. Suurin osa www-sivustojen käyttämistä varmenteista on noin parinkymmenen varmenteiden myöntäjän allekirjoittamia. Selainten ja käyttöjärjestelmien mukana olevien juurivarmenteiden määrä on moninkertainen. Mukana on muun muassa selkeästi paikallisia varmentajia, joita valtaosa käyttäjistä ei todennäköisesti koskaan tarvitse. Niin sanotun laajennetun tarkastuksen (Extended Validation, EV) varmenteet eivät ole koskaan saavuttaneet suurta suosiota. Varmentajien mukaan EVvarmenteet ovat erityisen turvallisia, sillä niitä myönnettäessa pyritään erityisen tarkasti varmistumaan varmenteen hakijan oikeudesta varmenteeseen. Käyttäjät eivät kuitenkaan ole tietoisia EVvarmenteiden erosta tavallisiin varmenteisiin verrattuna. Sovelluksessa ei ole mahdollista sulkea pois ei-ev-varmenteita, eikä tämä olisi markkinatilanteen kannalta edes järkevää. Kyseessä on käytännössä tällä hetkellä vain kalliimpien varmenteiden markkinointikeino. Myös DigiNotarilla ja Comodolla oli myynnissä EVvarmenteita. EV-varmenteiden myynti ei siis takaa sitä, että varmentajan tietoturva olisi kunnossa. X.509-varmenteiden toiminnan ymmärtäminen vaatii asiantuntijoiltakin perehtymistä. Suuren käyttäjäkunnan sovelluksissa, kuten selaimissa, on tehty varmenteiden käsittelyssä selkeitä toteutusvirheitä, joita uusissa toteutuksissa ja varmenteissa on ollut pakko toistaa taaksepäin yhteensopivuuden nimissä. Varmenteita lisäksi varastoidaan selainten välimuistiin sovellusten toiminnan nopeuttamiseksi, mikä saattaa pitkittää mitätöityjen varmenteiden hyväksikäyttöä. Suosituksia tietohallinnolle Arvioi organisaatiosi käyttäjien tarvitsemat juurivarmenteet. Älä ota käyttöön sokeasti kaikkia käyttöjärjestelmän ja selaimien mukana tulevia varmenteita. Lisää erityissuojattaviin kohteisiin vain tarvittavat juurivarmenteet. Lähetä erityissuojattavien sivustojen varmenteiden tiedot tiedoksi käyttäjille, kun ne muuttuvat. Selvitä turvattomat algoritmit, joita on suositeltu poistettavaksi hyväksyttyjen algoritmien listalta. Varmenteita hankiessasi arvioi varmentajan luotettavuus. Halvimman varmenteen ostaminen voi johtaa lisäkuluihin tulevaisuudessa. Oman varmennejärjestelmän tietoturvallinen ja luotettava ylläpitäminen maksaa. Älä ota omaan käyttöön varmenteita, joiden varmentaja ei ole käyttäjien järjestelmissä luotettujen joukossa. Uusi varmenteet ennen niiden vanhentumista. Näin vältät sen, että käyttäjäsi oppivat ohitta- 6

7 maan ilmoitukset varmennevirheistä. Mieti etukäteen, miten toimia, jos omilla sivuistoilla käytettyjen varmenteiden myöntäjä joutuu tietomurron kohteeksi ja sen juurivarmenne mitätöidään. Suosituksia käyttäjille Ota käyttöön selainten edistyneet turvaominaisuudet. Älä ohita varmenteisiin liittyviä virheilmoituksia selvittämättä niiden syitä. Pidä käyttöjärjestelmä ja selain päivitettyinä. Ole valppaana ja huomaa esimerkiksi, jos sinut ohjataankin yhtäkkiä salaamattomalle sivustolle. Suosituksia sovelluskehittäjille Toteutus ei saa toimia niin, että jos varmenteen tarkistus ei onnistu, jatketaan toimintaa käyttäjältä kyselemättä. Tutustu varmenteiden toimintaperiaatteisiin ennen sovelluksen toteuttamista. Varmista, että varmenteiden varmenneketjut varmistetaan oikein juurivarmentajaan saakka. Huomioi erityisesti Basic Constraintslaajennuksen tarkastaminen kaikista ketjun varmenteista. Toteuta sulkulistatoiminnallisuudet. Pyri löytämään hyvä tasapaino tietoturvan ja käyttäjille näytettyjen varmennevirheilmoitusten välillä. Kiinnitä erityistä huomiota siihen, että selainten käyttöliittymät esittävät varmenteisiin liittyvät virhetilanteet ja huomiot käyttäjälle selkeästi. Käyttäjän huijaaminen selaimen virheiden avulla pitää pyrkiä estämään. Monissa laitteissa käyttäjän ei ole edes mahdollista vaikuttaa itse luotettuihin juurivarmenteisiin. Tiedostavalle käyttäjälle ei edes tarjota mahdollisuutta parantaa tietoturvaansa. Päivitysmekanismeissa tulisi harkita hyväksyttyjen varmentajien määrittelemistä sovelluksen sisällä. Varmenteisiin merkityt käyttötarkoitukset tulee huomioida käytössä. Kehitysnäkymiä Käyttäjät luottavat sovellusvalmistajien ja käyttöjärjestelmien arvioon turvallisista juurivarmentajista. Luottamuksen menettäneiden juurivarmenteiden poistoprosessi pitää saada toimimaan nopeammin kuin tällä hetkellä. Olisi hyvä, jos selaimet käyttäisivät käyttöjärjestelmän keskitettyä varmennehakemistoa, jolloin käyttäjälle riittäisi yhden päivityksen tekeminen. Käyttäjille pitäisi tarjota työkaluja, joilla voi helposti tutkia, vertailla ja editoida eri sovellusten ja käyttöjärjestelmän juurivarmennelistoja. Luottamus on koko varmennejärjestelmän perusta, joten varmentajille on tärkeää toimia vastuullisesti murtoepäilytilanteissa ja tiedottaa aktiivisesti hyökkäyksistä ja niiden vaikutuksista. Tämä vähentää loppujen lopuksi myös yritysten kärsimiä taloudellisia menetyksiä. Vastuullisesti toiminut Comodo jatkaa toimintaansa, kun taas DigiNotar ajautui konkurssiin. Ilmoitusvelvollisuus tietomurroista asiakkaille kannustaisi parantamaan turvallisuutta. Itse allekirjoitettujen varmenteiden määrän kasvaminen johtaisi siihen, että käyttäjät turtuisivat ilmoituksiin varmennevirheistä. Suurissa järjestelmissä voi olla resurssit luoda omat varmenteet turvallisesti ja varmistaa, että käyttäjät lisäävät organisaation juurivarmenteet luotettujen varmentajien listaan. Pienemmillä toimijoilla ei ole tavallisesti resursseja ja osaamista toteuttaa varmennejärjestelmää tietoturvallisesti. Varmenteita tullaan tulevaisuudessa käyttämään yhä useammin myös ajettavien 7

8 sovellusten luotettavuudesta varmistumiseen. Varmistukset ovat käytössä Windows Vista- ja Windows 7 - käyttöjärjestelmien lisäksi kaikissa älypuhelinalustoissa. Tällöin myös ohjelmistovalmistajat joutuvat panostamaan sovellusten allekirjoittamiseen käytettyjen varmenteiden tietoturvaan. Allekirjoitettuja haittaohjelmia on jo käytetty useissa hyökkäyksissä, muun muassa laajalti uutisoidussa Stuxnethaittaohjelmatapauksessa. Tietoja varastavista haittaohjelmista on löydetty komponentteja, jotka etsivät järjestelmästä varmenteita ja näihin liittyviä salausavaimia. On myös esiitynyt tapauksia, joissa haittaohjelmat ovat lisänneet kehittäjien järjestelmissä olleeseen ohjelmakoodiin hyökkääjän haitallista ohjelmakoodia. Uusia varmenteisiin liittyviä tietoturvaominaisuuksia on tulossa selaimiin ainakin lisäosina. Google oli tuonut uusia varmenteisiin liittyvä tietoturvaominaisuuksia muunmuassa Chrome-selaimeensa ja asettaa paineita muille selainvalmistajille. SSL/TLS-suojattuja sivustoja käytetään yhä enenevässä määrin myös matkaviestimillä. Mobiililaitteiden päivittäminen on käyttäjälle paljon hankalampaa kuin tietokoneen eikä päivityksiä tule tarjolle riittävän nopeasti. SSL/TLS-protokollasta on nykyisin yleisimmin käytössä versio TLS 1.0, jonka tietoturvan tasosta on viime vuosina esitetty epäilyjä. Turvallisetkaan varmenteet eivät kykene suojaamaan turvatonta siirtoprotokollaa. Uudempien TLS-versioiden käyttöönotto lienee ennen pitkää väistämätöntä, mutta näitä tukevien salauskirjastojen käyttöönotto vaatii investointeja sekä palvelin- että asiakasohjelmistojen tekijöiltä. Varmennejärjestelmän ongelmien herättämät kehittäjät ovat esittäneet monia uusia tietoturvaratkaisuja. Osalla niistä ei ole vielä vakiintuneita nimityksiä. Ratkaisuista otetaan todennäköisesti käyttöön useampia, koska ne eivät suojaa samoilta uhilta. On toivottavaa, että ratkaisut eivät vaatisi käyttäjiltä suurta asiantuntemusta, vaan suojaisivat myös niin sanottuja tavallisia käyttäjiä. Vaarana on, että ratkaisut tekevät jo valmiiksi monimutkaisesta varmennejärjestelmästä vieläkin monimutkaisemman. Nimipalvelintietoihin perustuvat ratkaisut: DNS Certification Authority Authorization (CAA) -nimipalvelutietue - sellaisten juurivarmenteiden tunnisteiden liittäminen nimipalvelutietoon, jotka saavat myöntää varmenteita kyseiselle verkkoosoitteelle DNSSEC-ketjun liittäminen sivuston varmenteeseen DNS TLSA -nimipalvelutietue - palvelinvarmenteen tunnisteen sisällyttäminen verkko-osoitteen nimipalvelutietoihin Kaksi jälkimmäistä nimipalvelintietoihin perustuvista ratkaisuista vaatii DNSnimipalvelun turvalaajennusten DNSSEC:in käyttöönottoa. Tiukka integrointi yksistään DNSSEC-varmenteisiin ei ole täysin ongelmatonta, koska valta päättää luotettavista varmentajista siirtyy palvelun ylläpitäjältä ja käyttäjiltä verkkotunnusten myöntäjälle. Palvelupään ratkaisut: HTTP Strict Transport Security (HSTS): käytäntö, jossa wwwpalvelu voi ilmoittaa selaimelle, että sille pitäisi liikennöidä vain salatusti. OCSP Pinning tai Certificate Status Request: käytäntö, jossa wwwpalvelu tarkistaa oman varmenteensa tilan ja palauttaa sen selaimelle muun vastauksen osana. Sovelluspään ratkaisut: Certificate pinning tai domain pinning: vain joidenkin tiettyjen varmentajien hyväksyminen jonkun palvelun varmenteen myöntäjiksi. Juurivarmennelistojen paikallistaminen: juurivarmennelista sisältää vain yleisimmät ja kyseisellä alueella runsaasti käytetyt paikalliset juurivarmenteet. 8

9 Keskitetyt ratkaisut: Convergence: SSL/TLS-tutkija Moxie Marlinspiken kehittämä teknologia, jossa varmenteen luotettavuutta kysytään luotetuilta tahoila eli niinsanotuilta notaareilta. Notaarin voi perustaa vapaasti: järjestelmän käyttäjät pääättävät mihin notaareihin he luottavat. Meta CA: selainvalmistajien ja käyttöjärjestelmävalmistajien juurivarmennelistat korvaava yli-ca, johon selainvalmistajat ja käyttöjärjestelmävalmistajat luottaisivat. Keskitetty varmennehakemisto: eri tavoilla toteutettuja keskitettyjä varmennehakemistoja, joihin wwwpalvelun käyttämää varmennetta voi verrata, esimerkiksi Google, Tor ja EFF SSL Observatory. Toiminnallisuuksia eri skenaarioissa on verrattu taulukossa 1. Skenaarioista on suljettu pois tilanteet, joissa käyttäjän päätelaite on saastunut haittaohjelmalla. Taulukossa ei ole käsitelty myöskään muita sellaisia tilanteita, joissa hyökkääjä voi syöttää SSL-yhteyden sisälle omaa sisältöään, esimerkiksi sivuston XSShaavoittuvuuden avulla tai jos käytetty www-palvelu on murrettu. 9

10 Taulukko 1. Olemassaolevien ja ehdotettujen turvatoiminnallisuuksien antama suoja eri tilanteissa. Teknologia Varmenteiden myöntäjän erehdyttäminen väärillä tiedoilla Vierailu httpssuojatulla sivustolla ensi kertaa Vierailu httpssuojatulla sivustolla toista kertaa Httpsprotokollan pudottaminen httpprotokollaksi Muu manin-themiddlehyökkäys SSLsuojattu tietojen urkintasivusto 1) Varmenteen avainparin paljastuminen ulkopuoliselle Murto varmentajan järjestelmiin Sulkulistat (CRL) Ei Kyllä Kyllä Ei Ei Ei Kyllä Ei Ei OSCP Ei Kyllä Kyllä Ei Ei Ei Kyllä Ei Ei EV-varmenteet Kyllä Ei Ei Ei Ei Ei Ei Ei Ei DNS CAA RR a) Kyllä Ei Ei Ei Ei Ei Ei Ei Ei HSTS OSCP Pinning DNS TLSA RR a) Ei 2) DNSSEC-ketju varmenteessa a) Certificate pinning Pahantahtoinen varmentaja Huomioita Ei Ei Ei Kyllä Ei Ei Ei Ei Ei Toteutettu tällä kertaa vain Firefox-selaimessa Ei Kyllä Kyllä Ei Kyllä Ei Kyllä Ei Ei Vastausten uudelleenkäyttö on mahdollista. 2) Ei Kyllä Kyllä Ei Kyllä Kyllä Ei 2) Ei 2) Ei 2) Osa turvallisuustakuista siirtyy DNSSEC:in toteutettaviksi Kyllä Kyllä Ei Kyllä Kyllä Ei 2) Ei 2) Ei 2) Osa turvallisuustakuista siirtyy DNSSEC:in toteutettaviksi Ei Kyllä Kyllä Ei Kyllä Kyllä Ei Kyllä Ei Ei skaalautuva, käytössä selaimissa Windows Update, Googlen sivustot Convergence Ei Kyllä Kyllä Ei Kyllä Kyllä Ei Ei Kyllä Meta CA a) tarvitse enää ylläpitää Ei Kyllä Kyllä Ei Ei Kyllä Ei Kyllä Ei Selainvalmistajien ei listoja Keskitetty Ei Kyllä Kyllä Ei Kyllä Kyllä Ei Kyllä Kyllä varmennehakemisto a) Ei ole vielä käytössä 1) Sivusto pyrkii erehdyttämään käyttäjää oikean sivuston osoitetta muistuttavalla osoitteella. 2) Tosin DNSSEC voi auttaa 10

11 Tapauksista tiedottamista Diginotar: Comodo: Muita aiheeseen liittyviä dokumentteja Varmenteiden myöntäjien tietoturvavaatimuksia: Mozilla: Microsoft: Apple: Opera: Cabforumin 'Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates'-dokumentti: Hollannin viranomaiset ovat julkaisset tietoa DigiNotar-tapauksesta: Itävallan CERT-yksikkö on tuottanut arvion DigiNotar-tapauksen vaikutuksista Itävaltaan: ic.pdf Jarno Niemelän esitys ohjelmistoallekirjoitusten väärinkäytöstä: 11