Olen suunnilleen vuoden välein kirjoittanut internetin tietoturvasta, liittyen erityisesti SSL/TLS salaukseen ja sen toteutukseen nettisivuilla. Yleensä siksi, että näissä on ollut ongelmia ja mokia, joita ei pitäisi yhdenkään selkopäisen tietoturvavastaavan tehdä. Kuten tapauksissa "Suomalaisissa nettipankeissa vakavia tietoturvaongelmia", "Nordean verkkopankin tietoturvaongelmat" ja "Viranomaiset eivät osaa tehdä turvallisia nettipalveluita". Positiivista oli, että sentään parannustakin saatiin aikaan jollakin sektorilla, kuten "Viranomaiset ovat parantaneet nettipalveluidensa turvallisuutta".
No nyt lienee taas aika palata samaan aihepiiriin. Apunani oli tällä kertaa Calomel SSL Validation, joka onkin erinomainen työkalu paitsi ko. salauksen vahvuuden selvittämiseen, niin myöskin ei-toivottujen paskasalausten helppoon estämiseen Firefox-selaimesta. Kyseisen apuvälineen käyttö kertoo yhdellä vilkaisulla (ikonin väri) salauksen tason missä tahansa käyttämässäsi nettipalvelussa ja sitä klikkaamalla saa helposti lisätietoja asiasta. Kyseisen apuvälineen käyttö nostaa ainakin minulla nopeasti verenpainetta, kun käy ilmi, että sivustojen ylläpitäjät ja tietoturvavastaavat viittaavat kintaalle vahvalle salaukselle ja tietoturvalle.
No nyt lienee taas aika palata samaan aihepiiriin. Apunani oli tällä kertaa Calomel SSL Validation, joka onkin erinomainen työkalu paitsi ko. salauksen vahvuuden selvittämiseen, niin myöskin ei-toivottujen paskasalausten helppoon estämiseen Firefox-selaimesta. Kyseisen apuvälineen käyttö kertoo yhdellä vilkaisulla (ikonin väri) salauksen tason missä tahansa käyttämässäsi nettipalvelussa ja sitä klikkaamalla saa helposti lisätietoja asiasta. Kyseisen apuvälineen käyttö nostaa ainakin minulla nopeasti verenpainetta, kun käy ilmi, että sivustojen ylläpitäjät ja tietoturvavastaavat viittaavat kintaalle vahvalle salaukselle ja tietoturvalle.
Esimerkiksi ja vertailun vuoksi vaikkapa Nordean nettipankki vs SSL Labsin nettisivut:
Tämä on hyvin tyypillinen löytö, enkä jaksanut lähteä edes penkomaan muita nettipankkeja ja sivustoja vastaavien varalta. Mitä tuo kaikki sitten tarkoittaa Suomeksi? Avataan hieman käsitteitä:
Perferct Forward Secrecy (PFS) tarkoittaa yksinkertaisesti sitä, että vaikka palvelin vaarantuisi jonakin päivänä niin, että sen salausavaimet päätyisivät hakkerille, niin mikäli PFS on käytössä, tämä ei siltikään vaaranna aikaisemmin ko. palvelimelle tehtyjä yhteydenottoja eli niiden salausta. Ilman PFS:ää on mahdollista käyttää vaarantunutta salausavainta purkamaan kaikki palvelimen kanssa ikinä sillä käyty viestintä. PFS huolehtii käytössä ollessaan siitä, että jokainen yhteys palvelimelle (tarkemmin sanottuna "Key Exchange") muodostetaan "kertakäyttöisiä" epäsymmetrisiä salauksia käyttäen (DHE tai mieluiten ECDHE, "pitkäaikaisen" RSA: sijaan), jotka tuhotaan käytön jälkeen. Näin ollen niiden turvaama tieto pysyy salassa, vaikka palvelimen pääsalausavaimet joskus myöhemmin vaarantuisivatkin. Tämä on erinomainen ominaisuus, koska milloinkaan ei voi tietää, murtuuko jokin palvelin tai sen salausavain jälkikäteen. Tämän ominaisuuden käyttöönotto ei mitenkään ihmeemmin syö palvelimen resursseja tms. eli on aivan itsestään selvää, että se tulisi ehdottomasti ottaa käyttöön kaikissa https-yhteyksissä! Jostain syystä esimerkiksi Nordea ei kuitenkaan tee näin.
Ciphersuite kertoo salaussysteemipaketin, jota kyseinen nettisivusto käyttää. Salaussysteemipaketti on sarja tiettyjä valmiita ja tarkkaan määriteltyjä paketteja, joita myös selaimen asetuksista voi hienosäätää joko käyttöön tai käytöstä pois. Key Exchange kertoo, millä menetelmälllä "pääsalausavain" vaihdetaan tai luodaan palvelimen ja käyttäjän välillä. Signature kertoo puolestaan, mitä salausta palvelin käyttää todentamaan itsensä asiakkaalle digitaalisella allekirjoituksella. Bulk Cipher on se salausalgoritmi, jota siis käytetään tuolla "pääsalausavaimella" salaamaan suurinosa kaikesta tiedonsiirrosta asiakkaan koneelta palvelimelle saakka. MAC tarkoittaa kryptografista tiivistefunktiota, jolla varmistetaan viestien eheys (jottei viesti ole muuttunut matkan varrella) sekä yhdessä digitaalisen allekirjoituksen (signature) kanssa viestien todennus (että viestin on todella lähettänyt palvelin eikä joku muu).
RSA on vanhaa ja hidasta ja turvallisuudeltaan heikompaa (toki vielä aivan riittävää) käytettäväksi etenkin palvelimen tunnistamisessa, verrattuna elliptisten käyrien salaukseen (ECC), kuten ECDSA. Myös vanhempaa DSA:ta voidaan käyttää palvelimen tunnistamiseen, mutta se on sen verran heikkoa, että sen käytöstä on syytäkin ollut luopua pikkuhiljaa ECDSA:n eduksi. Avaintenvaihdossa (Key Exchange) RSA ei myöskään mahdollista PFS:ää, vaan PFS vaatii aina joko pelkän vanhamuotoisen DHE (Diffie-Hellman), tai uudemman ECDHE (elliptisten käyrien Diffie-Hellman) salauksen käytön kertakäyttöisen "pääsalausavaimen" siirtämiseksi turvallisesti käyttäjälle. Pelkällä RSA:lla voidaan kuitenkin, laiskanmiehenversiossa, hoitaa sekä palvelimen tunnistautuminen että "pääsalausavaimen" vaihtaminen käyttäjän ja palvelimen välillä, siksipä ehkä sen käyttö siinä tarkoituksessa onkin (mm. Nordealla) houkuttelevaa. Tietoturvan kannalta se on kuitenkin todella huono ajatus. Tietoturvan kannalta luultavasti paras vaihtoehto olisi käyttää yhdistelmää ECDSA_ECDHE, joka on myös palvelinta huomattavasti vähemmän resursseja kuluttavaa, kuin vanha ja hidas RSA-salaus.
Mainitsemani "pääsalausavain" on siis salausavain, joka siis vaihdetaan/muodostetaan palvelimen ja käyttäjän välillä ja sillä salataan pääosa kaikesta tietovirrasta netin ylitse https-yhteyksissä. "Pääsalausavainta" sitten käytetään symmetrisellä salausalgoritmilla, kuten vaikkapa RC4, AES tai Camellia. RC4 on jonosalain, jonka turvallisuus lienee vähän niin ja näin (toki sitäkään ei ole "vielä murrettu", mutta väärin käytettynä ja sovellettuna se on hyvin riskialtis). AES ja etenkin sen SSL Labsissakin käytetty versio, AES_128_GCM_SHA256 puolestaan on hyvin turvallinen ja takaa myös osaltaan viestin eheyttä, eli tekee viestien muuttamisesta ja väärentämisestä vaikeampaa ja salauksesta tietyllä tapaa voinee sanoa, "vakaampaa". Periaattessa AES_256 olisi vahvempaa salausta, mutta ottaen huomioon RSA, DSA, DHE, ECDSA ja ECDHE avainten vahvuuden, joka ei yleensä ole reaalimaailmassa kuin saman verran kuin AES_128, tällä ei ole käytännön merkitystä. Camelliaa harvemmin tapaa netissä käytettävän, vaikka se ilmeisesti on yhtälailla vahva tai jopa vahvempi kuin AES-salaus on. Muitakin vaihtoehtoja symmetriseksi salausalgoritmeiksi toki on, mutta ne ovat harvinaisempia käytössä.
MAC:ssa on myöskin valinnanvaraa palvelimilla. On MD5, SHA-1 ja SHA-256/384, sekä eksoottisempi AEAD. Näistä MD5 on täysin epäturvallinen, SHA-1 turvallisuus on riittämätön, SHA-256/384 on hyvä ja luultavasti uusi AEAD on kaikkein paras. Yleisimmin käytössä on juurikin SHA-1, kuten Nordeankin tapauksessa, kenties siksi että se on "vanha ja tuttu" tiivistefunktio. SHA-256/384 tekee kuitenkin tuloaan, joskin turhaan, koska sen sijaan voisi siirtyä suoraan käyttämään AEAD:tä.
Sertifikaattiauktoriteeteista (CA) ja palvelinten avainten varmentamisesta on myös syytä puhua. Aina välillä tulee ilmi tapauksia, joissa sertifikaattiauktoriteetin avaimia on käytetty väärentämään palvelinten sertifikaatteja. Nämä ovat vaarallisia hyökkäyksiä, koska selaimet tuppaavat luottamaan sertifikaattiauktoriteetin digitaalisiin allekirjoituksiin, eli siihen, että tietyn palvelimen X avain on oikeasti sen palvelimen avain, koska tämä (CA) niin digitaalisella allekirjoituksellaan varmistaa. Tähän sudenkuoppaan on olemassa muutamia vastatoimia, kuten selaimen pitäminen päivitettynä (jolloin väärät sertifikaatit ja CA:ta on päivitetty sinnekin) tai esimerkiksi HTTPS Everywhere lisäosan käyttäminen (ja siinä SSL Observatory). Mikäli tämmöinen hyökkäys sattuu kohdistumaan nettisivulle jota käytät, millään salauksen vahvuudella tai menetelmillä ei ole luonnollisestikaan mitään suojaa eikä merkitystä. Onneksi nämä ovat kuitenkin harvinaisia hyökkäyksiä. Yleisempiä tälle sektorille sijoittuvia ongelmia ovat hyökkäykset, joissa CA puuttuu tai on väärä ja näistä selain osaa kyllä varoittaa käyttäjää normaalitilanteissa.
Avainten koosta sitten vielä muutama sananen. RSA:n, DHE:n ja DSA:n avainkoon tulisi aina olla vähintään 2048 bittiä. ECC:ssä puolestaan avainkoon tulisi olla vähintään luokkaa n. 250 bittiä, mieluusti toki yli 500 bittiä. RC4, AES ja Camellia puolestaan käyttävätkin aina 128 tai 256 bittistä salausta, joka onkin riittävää. Tiivistefunktioissa tulisi käyttää vähintään 256 bittistä vaihtoehtoa, kuten SHA-256/384 tai AEAD. Huomaa, että tiivistefunktioista SHA-1 on vain 160 bittinen ja muutenkin epäturvallinen MD5 vain 128 bittiä!
Yleensä salauksen "bittimääräisellä" vahvuudella ei ole ongelmia nettipalveluissa eikä käytännössäkään, vaan salauksen puutteet ovat aivan jossain muualla...kuten juuri PFS:n käyttämättömyydessä ja huteran RC4 käytössä, puhumattakaan murtuneen MD5 tai huteran SHA-1 tiivistefunktioiden käytössä! Mitään käytännön syytä olla käyttämättä suurikokoisia avaimia ei oikeastaan ole olemassakaan, koska nopeuserot ovat täysin mitättömät. Itse asiassa esimerkiksi ECC:n 500+ bittinen avain on jopa nopeampi käyttää kuin vaikkapa 4096 bittinen RSA.
Kuten jo totesin, mitään järkeviä syitä käyttää heikkoja avaimia tai avainkokoja ei oikein olemassakaan. Tällä sektorilla olevat puutteet, kuten tässä tapausesimerkissä Nordean suhteen, kertovat vain karua kieltään kyseisen nettipalvelun ylläpitäjän viitseliäisyydestä ja tietoturvataidoista. Asiat olisi melko helppo ja vaivatonta korjata, siten pitäen huolta siitä, että salaus ei ainakaan petä. Ei nyt, eikä tulevaisuudessakaan.
Perferct Forward Secrecy (PFS) tarkoittaa yksinkertaisesti sitä, että vaikka palvelin vaarantuisi jonakin päivänä niin, että sen salausavaimet päätyisivät hakkerille, niin mikäli PFS on käytössä, tämä ei siltikään vaaranna aikaisemmin ko. palvelimelle tehtyjä yhteydenottoja eli niiden salausta. Ilman PFS:ää on mahdollista käyttää vaarantunutta salausavainta purkamaan kaikki palvelimen kanssa ikinä sillä käyty viestintä. PFS huolehtii käytössä ollessaan siitä, että jokainen yhteys palvelimelle (tarkemmin sanottuna "Key Exchange") muodostetaan "kertakäyttöisiä" epäsymmetrisiä salauksia käyttäen (DHE tai mieluiten ECDHE, "pitkäaikaisen" RSA: sijaan), jotka tuhotaan käytön jälkeen. Näin ollen niiden turvaama tieto pysyy salassa, vaikka palvelimen pääsalausavaimet joskus myöhemmin vaarantuisivatkin. Tämä on erinomainen ominaisuus, koska milloinkaan ei voi tietää, murtuuko jokin palvelin tai sen salausavain jälkikäteen. Tämän ominaisuuden käyttöönotto ei mitenkään ihmeemmin syö palvelimen resursseja tms. eli on aivan itsestään selvää, että se tulisi ehdottomasti ottaa käyttöön kaikissa https-yhteyksissä! Jostain syystä esimerkiksi Nordea ei kuitenkaan tee näin.
Ciphersuite kertoo salaussysteemipaketin, jota kyseinen nettisivusto käyttää. Salaussysteemipaketti on sarja tiettyjä valmiita ja tarkkaan määriteltyjä paketteja, joita myös selaimen asetuksista voi hienosäätää joko käyttöön tai käytöstä pois. Key Exchange kertoo, millä menetelmälllä "pääsalausavain" vaihdetaan tai luodaan palvelimen ja käyttäjän välillä. Signature kertoo puolestaan, mitä salausta palvelin käyttää todentamaan itsensä asiakkaalle digitaalisella allekirjoituksella. Bulk Cipher on se salausalgoritmi, jota siis käytetään tuolla "pääsalausavaimella" salaamaan suurinosa kaikesta tiedonsiirrosta asiakkaan koneelta palvelimelle saakka. MAC tarkoittaa kryptografista tiivistefunktiota, jolla varmistetaan viestien eheys (jottei viesti ole muuttunut matkan varrella) sekä yhdessä digitaalisen allekirjoituksen (signature) kanssa viestien todennus (että viestin on todella lähettänyt palvelin eikä joku muu).
RSA on vanhaa ja hidasta ja turvallisuudeltaan heikompaa (toki vielä aivan riittävää) käytettäväksi etenkin palvelimen tunnistamisessa, verrattuna elliptisten käyrien salaukseen (ECC), kuten ECDSA. Myös vanhempaa DSA:ta voidaan käyttää palvelimen tunnistamiseen, mutta se on sen verran heikkoa, että sen käytöstä on syytäkin ollut luopua pikkuhiljaa ECDSA:n eduksi. Avaintenvaihdossa (Key Exchange) RSA ei myöskään mahdollista PFS:ää, vaan PFS vaatii aina joko pelkän vanhamuotoisen DHE (Diffie-Hellman), tai uudemman ECDHE (elliptisten käyrien Diffie-Hellman) salauksen käytön kertakäyttöisen "pääsalausavaimen" siirtämiseksi turvallisesti käyttäjälle. Pelkällä RSA:lla voidaan kuitenkin, laiskanmiehenversiossa, hoitaa sekä palvelimen tunnistautuminen että "pääsalausavaimen" vaihtaminen käyttäjän ja palvelimen välillä, siksipä ehkä sen käyttö siinä tarkoituksessa onkin (mm. Nordealla) houkuttelevaa. Tietoturvan kannalta se on kuitenkin todella huono ajatus. Tietoturvan kannalta luultavasti paras vaihtoehto olisi käyttää yhdistelmää ECDSA_ECDHE, joka on myös palvelinta huomattavasti vähemmän resursseja kuluttavaa, kuin vanha ja hidas RSA-salaus.
Mainitsemani "pääsalausavain" on siis salausavain, joka siis vaihdetaan/muodostetaan palvelimen ja käyttäjän välillä ja sillä salataan pääosa kaikesta tietovirrasta netin ylitse https-yhteyksissä. "Pääsalausavainta" sitten käytetään symmetrisellä salausalgoritmilla, kuten vaikkapa RC4, AES tai Camellia. RC4 on jonosalain, jonka turvallisuus lienee vähän niin ja näin (toki sitäkään ei ole "vielä murrettu", mutta väärin käytettynä ja sovellettuna se on hyvin riskialtis). AES ja etenkin sen SSL Labsissakin käytetty versio, AES_128_GCM_SHA256 puolestaan on hyvin turvallinen ja takaa myös osaltaan viestin eheyttä, eli tekee viestien muuttamisesta ja väärentämisestä vaikeampaa ja salauksesta tietyllä tapaa voinee sanoa, "vakaampaa". Periaattessa AES_256 olisi vahvempaa salausta, mutta ottaen huomioon RSA, DSA, DHE, ECDSA ja ECDHE avainten vahvuuden, joka ei yleensä ole reaalimaailmassa kuin saman verran kuin AES_128, tällä ei ole käytännön merkitystä. Camelliaa harvemmin tapaa netissä käytettävän, vaikka se ilmeisesti on yhtälailla vahva tai jopa vahvempi kuin AES-salaus on. Muitakin vaihtoehtoja symmetriseksi salausalgoritmeiksi toki on, mutta ne ovat harvinaisempia käytössä.
MAC:ssa on myöskin valinnanvaraa palvelimilla. On MD5, SHA-1 ja SHA-256/384, sekä eksoottisempi AEAD. Näistä MD5 on täysin epäturvallinen, SHA-1 turvallisuus on riittämätön, SHA-256/384 on hyvä ja luultavasti uusi AEAD on kaikkein paras. Yleisimmin käytössä on juurikin SHA-1, kuten Nordeankin tapauksessa, kenties siksi että se on "vanha ja tuttu" tiivistefunktio. SHA-256/384 tekee kuitenkin tuloaan, joskin turhaan, koska sen sijaan voisi siirtyä suoraan käyttämään AEAD:tä.
Sertifikaattiauktoriteeteista (CA) ja palvelinten avainten varmentamisesta on myös syytä puhua. Aina välillä tulee ilmi tapauksia, joissa sertifikaattiauktoriteetin avaimia on käytetty väärentämään palvelinten sertifikaatteja. Nämä ovat vaarallisia hyökkäyksiä, koska selaimet tuppaavat luottamaan sertifikaattiauktoriteetin digitaalisiin allekirjoituksiin, eli siihen, että tietyn palvelimen X avain on oikeasti sen palvelimen avain, koska tämä (CA) niin digitaalisella allekirjoituksellaan varmistaa. Tähän sudenkuoppaan on olemassa muutamia vastatoimia, kuten selaimen pitäminen päivitettynä (jolloin väärät sertifikaatit ja CA:ta on päivitetty sinnekin) tai esimerkiksi HTTPS Everywhere lisäosan käyttäminen (ja siinä SSL Observatory). Mikäli tämmöinen hyökkäys sattuu kohdistumaan nettisivulle jota käytät, millään salauksen vahvuudella tai menetelmillä ei ole luonnollisestikaan mitään suojaa eikä merkitystä. Onneksi nämä ovat kuitenkin harvinaisia hyökkäyksiä. Yleisempiä tälle sektorille sijoittuvia ongelmia ovat hyökkäykset, joissa CA puuttuu tai on väärä ja näistä selain osaa kyllä varoittaa käyttäjää normaalitilanteissa.
Avainten koosta sitten vielä muutama sananen. RSA:n, DHE:n ja DSA:n avainkoon tulisi aina olla vähintään 2048 bittiä. ECC:ssä puolestaan avainkoon tulisi olla vähintään luokkaa n. 250 bittiä, mieluusti toki yli 500 bittiä. RC4, AES ja Camellia puolestaan käyttävätkin aina 128 tai 256 bittistä salausta, joka onkin riittävää. Tiivistefunktioissa tulisi käyttää vähintään 256 bittistä vaihtoehtoa, kuten SHA-256/384 tai AEAD. Huomaa, että tiivistefunktioista SHA-1 on vain 160 bittinen ja muutenkin epäturvallinen MD5 vain 128 bittiä!
Yleensä salauksen "bittimääräisellä" vahvuudella ei ole ongelmia nettipalveluissa eikä käytännössäkään, vaan salauksen puutteet ovat aivan jossain muualla...kuten juuri PFS:n käyttämättömyydessä ja huteran RC4 käytössä, puhumattakaan murtuneen MD5 tai huteran SHA-1 tiivistefunktioiden käytössä! Mitään käytännön syytä olla käyttämättä suurikokoisia avaimia ei oikeastaan ole olemassakaan, koska nopeuserot ovat täysin mitättömät. Itse asiassa esimerkiksi ECC:n 500+ bittinen avain on jopa nopeampi käyttää kuin vaikkapa 4096 bittinen RSA.
Kuten jo totesin, mitään järkeviä syitä käyttää heikkoja avaimia tai avainkokoja ei oikein olemassakaan. Tällä sektorilla olevat puutteet, kuten tässä tapausesimerkissä Nordean suhteen, kertovat vain karua kieltään kyseisen nettipalvelun ylläpitäjän viitseliäisyydestä ja tietoturvataidoista. Asiat olisi melko helppo ja vaivatonta korjata, siten pitäen huolta siitä, että salaus ei ainakaan petä. Ei nyt, eikä tulevaisuudessakaan.
Ajonhallintakeskus ajokorttitietoineen aika heikosti suojattu, outoa. Kokeilin oppejasi jälleen kerran, kiitosta.
VastaaPoista