TTY / Tietoturvallisuuden jatkokurssi / Harjoitustyö 2011 / Luonnosvaihe

Joonas Koivunen

CA-järjestelmän korvaaminen SSL/TLS autentikoinnissa

Johdanto

Selaimesi käyttää Certificate Authority (CA) -järjestelmää todentaakseen yhteytesi tälle koulun palvelimelle. Oli kyseessä koulun TWiki-palvelin tai pankkisi verkkopalvelu, palvelimen todentamisen varaan rakentuu luottamuksellisuus; jos vastapuolena onkin oikealle pankille viestisi välittävä hyökkääjä viestiesi luottamuksellisuus menetetään.

Tässä harjoitustyössä esittelen eri tapoja hyökätä tätä mekanismia vastaan ja käyn läpi erilaisia ratkaisuvaihtoehtoja. Rajaan tarkastelun WWW:n useimmin käyttämälle tasolle.

Sertifikaattipohjainen todennus

PKI eli julkisen avaimen infrastruktuuri on perinteisesti WWW:ssä rakennettu X.509 sertifikaattien varaan. Sertifikaatissa on kryptografisten tietojen lisäksi tunnistetietoja, joilla esimerkiksi WWW-selain voi vahvistaa sertifikaatin kuuluvan juuri sen nimiselle palvelimelle, jonne käyttäjä oli halunnut ottaa yhteyttä.

Sertifikaatti on aina myöntäjän (CA) allekirjoittama. Myöntäjän sertifikaatti on joko myöntäjän itsensä, ylemmän tason myöntäjän tai samantasoisen myöntäjiä allekirjoittavan tahon allekirjoittama. Allekirjoittavien tahojen sertifikaattien allekirjoituksista muodostuvaa graafia verrataan tunnettujen ja luotettujen tahojen sertifikaatteihin; palvelimen lähettämä sertifikaatti todetaan luotetuksi jos graafista löytyy luotetun tahon allekirjoitus.

Keitä ovat luotetut tahot?

Sertifikaatteja myöntävät tahot ovat suurimmaksi osaksi yrityksiä [1], jotka ovat saaneet sertifikaattinsa käyttöjärjestelmien tai sovellusten luotetut sertifikaatit -listalle. Nämä yritykset myöntävät sertifikaatteja rahasummaa vastaan maksaville asiakkaille, jotka haluavat että heidän käyttäjät pääsevät heidän turvallisille sivuilleen ongelmitta. Yritysten muodostama haavoittuvuus on selvä, yrityksethän ovat mukana tehdäkseen rahaa. Tätä tosiasiaa hyödyntäviä tuotteita on markkinoilla, esimerkiksi laite, joka vaatii vain luotetun myöntämiseen tarkoitetun sertifikaatin ja mahdollistaa sen jälkeen kaiken liikenteen kaappaamisen. [2]

Maailman muuttuessa kokoajan Internet-riippuvaisemmaksi ei ole mahdoton uhkakuva, että valtion edustajat vaatisivat näiden luotettujen tahojen yhteistyötä kansallista turvallisuutta edistävässä hankkeessa, esimerkiksi myöntämällä valtion edustajan vaatimia sertifikaatteja auttamaan luottamuksellisuuden rikkomisessa.

Myöntäjiin muodostettu luottamus

Vaikka käyttäjällä on usein mahdollisuus valita itse luotetut varmenteita myöntävät tahot, ei se ole käytännössä mahdollista koska on mahdotonta pystyä selvittämään kunkin yrityksen luotettavuus. Suuri yleisö luottaa sovellus- tai käyttöjärjestelmävalmistajan arvostelukykyyn. Sovellus- ja käyttöjärjestelmävalmistajien tarkoitusperänä on mahdollistaa mahdollisimman hyvä yhteensopivuus, etteivät kilpailijat saa etulyöntiasemaa paremman yhteensopivuuden myötä.

Tätä kirjoittaessa selainvalmistaja Mozilla ilmoitti poistavansa luottamuksen erääseen alimman tason myöntäjään [3]. Luottamus loppui kun sertifikaatin myöntänyt yritys ilmoitti että sertifikaatilla on myönnetty kryptografisesti epäluotettavia sertifikaatteja, joiden yksityiset avaimet ovat jo saattaneet paljastua.

Epäluotettavia sertifikaatteja allekirjoittavien tahojen poistaminen luotettujen listalta on hyvä asia, mutta ongelmallista on tämän luottamuksen päivittäminen asiakkaille. Esimerkiksi juurikin selainten tapauksessa ainoa käytetty tapa "lopettaa luottamus" myöntäjään on selainpäivityksen lataaminen.

Todentamistarve

Jos keskitytään alkuperäiseen todentamistarpeeseen, eli kysymykseen siitä, onko kohdepalvelin se joksi käyttäjä sitä luulee. Palvelin on yhteydessä Internetiin, sillä on IP-osoite ja DNS-nimi, jonka käyttäjä antaa sovellukselle ottaakseen yhteyttä palvelimeen; sovellus saa yhteyden muodostamisen yhteydessä palvelimen sertifikaatin tutkittavakseen.

Jo ennen kuin saa tutkittavakseen mitään sertifikaattia palvelimelta, on hän saattanut joutua hyökkäyksen kohteeksi ainakin DNS-palvelimen toimesta. Mikäli hyökkääjällä, joka vaikuttaa myös DNS-palvelimen toimintaan on mahdollisuus saada minkä tahansa lukuisista yleisesti luotetuista CA -toimijoista allekirjoittamaan palvelimensa sertifikaatti, esittää käyttäjän sovellus hyökkääjän palvelimen sertifikaatin luotettuna. Tilanteesta toipuminen vaatisi käyttäjältä erityistä huomaavaisuutta; hänen pitäisi pitää itse kirjaa käyttämiensä palvelimien sertifikaateista, mikä olisi taas erittäin huono yleisen käytettävyyden kannalta.

Edellä mainittuja ”Man In the Middle” (MItM) hyökkäyksiä ajatellen on kehitetty Perspectives [4].

Perspectives

Toisin kuin CA -toimijoiden luotettavuuteen nojaavassa nykyisessä mallissa, Perspectives luo luottamuksen sertifikaattiin ympäri maapalloa sijaitsevien notaarien avulla. Luotaessa yhteyttä palvelimelle pyydetään notaareilta heidän näkemyksensä palvelimen sertifikaatista. Jos kaikki osapuolet ovat samaa mieltä palvelimen käyttämästä sertifikaatista, käyttäjä voi olla varma siitä että kukaan ei ole ainakaan hänen ja palvelimen välissä suorittamassa MItM -hyökkäystä. Käyttäjä voi itse valita notaarit, joihin haluaa luottaa.

Perspectives mallissa notaarit ja sovellus pitävät kirjaa näkemistään sertifikaateista SSH:sta tutun TOFU/POP ("Trust on first use", "Persistence of Pseudonym") mallin mukaisesti. Käytännössä tätä historiatietoa voidaan käyttää välimuistina ja ongelmatilanteiden ratkaisuun; esimerkkinä tilanne jossa palvelimen sertifikaatti on vaihtunut, mutta historiatiedosta huomataan että edellinen sertifikaatti oli määrätty erääntyväksi huomenna.

Perspectives sisältää avoimen lähdekoodin (GPLv3) notaarisovelluksen ja Firefox liitännäisen. Firefox liitännäinen toimii normaalisti CA-pohjaisen luottamuksen vierellä, mutta estää Firefoxin varoitukset itse allekirjoitetusta sertifikaatista mikäli kaikki notaarit näkevät saman sertifikaatin.

Suurin riski Perspectives liitännäisen käyttöön on notaarin mahdollisuus valvoa käyttäjän HTTPS-selausta; tähän otetaan kantaa projektin notaaripalvelinsivulla [5] mainitsemalla että yksikään heidän palvelimistaan ei tallenna kyselyitä tehneiden IP-osoitteita.

Lisäksi Perspectives on erityisen haavoittuvainen lähellä palvelua tapahtuvaan MItM -hyökkäykseen, jossa hyökkääjä sijoittautuu Internetin ja palvelun väliin, halliten sen kaikkea liikennettä; tälläisessä tilanteessa CA-pohjainen tarkistus saattaa olla luotettavampi kuin koko maailmalle näkyvä hyökkääjän itseallekirjoitettu sertifikaatti. Tätä riskiä voidaan pienentää huomaamalla sertifikaatin vaihtuminen historiatiedoista, vaikkei sellaista olisi pitänyt tapahtua suhteessa erääntymispäivämääriin. Lähellä asiakasta tapahtuva MItM huomataan historiatiedon ja notaarien joko väärennettyjen allekirjoitusten tai yhteydenmuodostusongelmien myötä. [4]

Convergence.io

Convergence.io [6] on rakennettu Perspectives -projektin työn päälle, jonka perimmäisenä ideana on tehdä luottamuksesta mahdollisimman joustavaa. Perspectives -mallissa nojaudutaan vain ja ainoastaan nähtyihin sertifikaatteihin, mutta Convergence.io mahdollistaa lukuisien eri mallien yhdistämisen.

Perspectives -mallista tutut notaarit voivat perustaa luottamuksensa tiettyyn sertifikaattiin esimerkiksi perinteisen CA-mallin mukaan, DNSSEC -laajennuksien välittämiin tietoihin tai historialliseen näkemykseensä palvelimen sertifikaatista. Convergence.io tarttuu myös notaarien valvomismahdollisuuteen lisäämällä notaarille mahdollisuuden toimia välityspalvelimena convergence.io kyselyille. [7]

Convergence.io:lle on avoimen lähdekoodin (GPLv3) notaarisovelluksen ja Firefox liitännäisen. Notaarisovellukseen on tällä hetkellä toteutettu kaksi tarkistustapaa: Perspectives-tyylinen sertifikaatin tarkistaminen ja Google Certificate Catalog -palvelun avulla tarkistaminen. [8] Projektin wiki-sivuille on kirjoitushetkellä listattuna yli 30 julkista notaaripalvelinta [9].

Perspectives ja Convergence.io kärsivät osittain samoista ongelmista, joista yksi on että tietyt palveluntarjoajat käyttävät eri palvelimilla eri sertifikaatteja vaikka palvelimet ovat saman DNS-nimen takana. Toinen yhteinen ongelmallinen kohta on yksityiset palvelut koska notaarit eivät voi mitenkään nähdä näitä yksityisten verkkojen palveluita. [7]

Sovereign Keys

Sovereign Keys on EFF:n marraskuussa 2011 julkituoma projekti [10] jonka tarkoituksena on tuoda yksi lisäkomponentti palvelimen sertifikaatin aitouden varmentamiseksi.

Järjestelmä rakentuu organisaatio- tai TLD kohtaiseen avaimeen (SK), jolla allekirjoitetaan käytetyt sertifikaatit (mahdollisen CA-allekirjoituksen lisäksi). Kyseinen avain saatetaan "aikajana"-palveluiden tietoon, jotka kirjaavat käytetyn SK-avaimen tietokantaansa.

Aikajana-palvelun suunnittelussa on kiinnitetty erityistä huomiota sen eheyden varmistamiseen, eli että palvelun ylläpitäjä tai hyökkääjä ei voi mennä muokkaamaan sinne jo julkaistua tietoa. Lisäksi jokaisesta tallennetusta avaimesta pitää olla todistusaineistoa, kuten esimerkiksi CA-hierarkian tiiviste tai DNSSEC allekirjoitus.

Sovereign Keys on tällä hetkellä suunnitteluvaiheessa eikä sen suunnitteludokumentaatiossa [11] kuvata esimerkiksi miten esittelyssä mainittavaa Tor -palvelua [10] on tarkoitus hyödyntää asiakassovelluksessa. Mitään koodia projektilta ei löydy.

CA -järjestelmän parantaminen

Marraskuussa 2011 Googlen tutkijat julkaisivat suunnitelmaluonnoksen jossa hahmotellaan CA -toimijoiden menetelmien muuttamista läpinäkyvämmäksi ja siten vikasietoisemmaksi. Suunnitelma rakentuu julkisesti tarkasteltavaan sertifikaattilokiin [12], jonne kirjataan jokainen myönnetty sertifikaatti ja todistusaineisto myöntämisen takana. Asiakasohjelmiston vastuulle tulee sertifikaatin myöntäneen CA:n sertifikaattilokin tutkiminen sertifikaatin aitouden varmistamiseksi.

Suunnitelma on hyvin alustavaa laatua, eikä projektiin liity valmista koodia.

Yhteenveto

Kaikissa läpikäydyissä järjestelmissä on olennaista että uutta on lähdetty rakentamaan olemassaolevan järjestelmän rinnalle, kantavana ajatuksena se ettei Internettiä tarvitse rakentaa uudelleen. Tämä on erittäin hyvä asia niin ylläpitäjien kuin loppukäyttäjienkin kannalta. Viitatut suunnitteludokumentit ottavat kantaa ehdotettujen järjestelmien käytettävyyteen, eli siihen, millainen varoitus tai virheilmoitus käyttäjälle esitetään ongelmatilanteissa.

Suurimmat esteet minkään mainitun järjestelmän käyttöönottoon ovat mm. selain- ja käyttöjärjestelmävalmistajat sekä mahdollisesti CA -teollisuus, joka saattaisi olla menettämässä markkinoitaan. On myös huomattava että mikään ratkaisuista ei ole yleisesti hyväksytty Internetin "parannuskeino". Hyvä uutinen kuitenkin on, että parannuskeinoa etsitään.

Lähteet

  1. C. Ellison, B. Scheiner: Ten Risks of PKI http://www.schneier.com/paper-pki-ft.txt
  2. Doug Ross, blogiartikkeli http://directorblue.blogspot.com/2006/07/think-your-ssl-traffic-is-secure-if.html
  3. Mozilla Security Blog -artikkeli, http://blog.mozilla.com/security/2011/11/03/revoking-trust-in-digicert-sdn-bhd-intermediate-certificate-authority/
  4. D. Wendlandt, D. G. Andersen, A. Perrig: Perspectives: Imporing SSH-style Host Authentication with Multi-Path Probing http://perspectivessecurity.files.wordpress.com/2011/07/perspectives_usenix08.pdf
  5. Perspectives Project: Notary Servers http://perspectives-project.org/notary-servers/
  6. Thoughtcrime Labs: convergence.io http://convergence.io/index.html
  7. M. Marlinspike, BlackHat USA 2011 esitys "SSL And The Future Of Authenticity" http://www.youtube.com/watch?v=Z7Wl2FW2TcA
  8. Convergence lähdekoodin verifier moduuli https://github.com/moxie0/Convergence/tree/master/server/convergence/verifier
  9. Convergence.io projektin notaarisivu https://github.com/moxie0/Convergence/wiki/Notaries
  10. Electronic Frontier Foundation https://www.eff.org/sovereign-keys
  11. Electronic Frontier Foundation, Sovereign Keys suunnitteludokumentti https://git.eff.org/?p=sovereign-keys.git;a=blob_plain;f=sovereign-key-design.txt;hb=master
  12. B. Laurie, A. Langley: Certificate Authority Transparency and Auditability http://www.links.org/files/CertificateAuthorityTransparencyandAuditability.pdf

SivuTiedotLaajennettu edit

Vaativuus Jatko
Valmius Valmis
Tyyppi Ydin
Luokitus Käytännöt
Mitä Luottamuksellisuus
Miltä Useita
Missä Useita
Kuka Titu-ammattilainen
Milloin Muu
Miksi Politiikka
Print version |  PDF  | History: r6 < r5 < r4 < r3 | 
Topic revision: r6 - 13 Dec 2011 - 13:38:18 - JoonasKoivunen?
 

TUTWiki

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TUTWiki? Send feedback