Meillä on tapana tänäpäivänä salata kaikki mahdollinen liikenne ja varmistaa tietojen aitouksia. Verkkosivuilla on käytössä SSL/TLS-pohjainen HTTPS-yhteys, joka suojaa liikenteen esimerkiksi tähän sivustolle. Lisäksi käytämme tarvittaessa erilaisia VPN-yhteyksiä. Mutta yksi erikoisuus on siis että nimipalvelinliikennettä ei suojata tänäpäivänä oikein mitenkään. Se on siis täysin salaamatonta!
Sisällysluettelo
Nimipalvelin on internetin puhelinluettelo
Nimipalvelin on yksinkertaisuudessa internetin puhelinluettelo. Sielä on nimiä (verkko-osoitteita, kuten mt-tech.fi) ja IP-osoitteita kuten 185.168.204.248 tai 2a0b:a700:2:1::103. Kysymme siis usein nimipalvelimelta minne haluamme mennä ja se kertoo meille sitten IP-osoitteen. Tämä olisi sama juttu kun soitettaisiin Fonectalle ja kysyttäisiin puhelinnumeroa.
Tässä alla on kaaviossa, miten nimipalvelinkyselyt tapahtuvat normaalisti ilman ongelmia. Näin se pääsääntöisesti tapahtuu.
- Kysytään resolver-nimipalvelimet (esim. 1.1.1.1 / CloudFlare-DNS) missä on mt-tech.fi
- Mikäli 1.1.1.1 nimipalvelimella tätä ei ole välimuistissa, niin ensiksi lähdetään kysymään missä .fi – nimipalvelimet löytyvät juuri nimipalvelimilta (root) (puuttuu kuvasta)
- Tämän jälkeen root-nimipalvelimet vastaavat että .fi löytyy a.fi:stä esimerkiksi.
- Ficoran fi-nimipalvelimet vastaavat että mt-tech.fi nimipalvelimet löytyvät ns1.truong.fi:stä.
- Nyt kysytään ns1.truong.fi nimipalvelimelta ja saadaan tulokseksi mt-tech.fi palvelimen IP-osoitteen 185.168.204.248.
Normaalisti tämä toimii oikein, mutta koska tässä mikään pyyntö ei ole allekirjoitettu niin sen oikeellisuutta ei voida tarkistaa että onko IP-osoite vastaus todellisuudessa tullut nimipalvelimelta ns1.truong.fi / 185.168.204.250 vai tuliko muualta?
Tämän olen jo korjannut, DNSSECillä, joka on allekirjoittanut tämän verkkotunnuksen. DNSSECin avulla Resolver-nimipalvelin, tässä tapauksessa CloudFlare-DNS voi varmistaa allekirjoituksesta, että nimipalvelinhaussa kaikki allekirjoitukset täsmäävät siihen mihin nimipalvelin itse luottaa. Mikäli allekirjoituksissa on jotakin pielessä, niin nimipalvelimet palauttavat SERVERFAIL-virheilmoituksen ja estää kokonaan verkkosivulle pääsyn. Huomioitavaa kuitenkin on, ettei kaikki resolver-nimipalvelimet tarkista DNSSECiä, joten tässä ei ole hyötyä jos sitä ei tarkisteta.
Tästä syystä on suositeltavaa ottaa kaikissa omissa verkkotunnuksissa DNSSEC käyttöön. Tällä blogissani on jo fi-verkkotunnuksille ohjetta. Yleisimmät verkkotunnuspäätteet tukevat DNSSECiä.
Aitous varmistettu, mutta entäs se salaus
DNSSECillä varmistimme nimipalvelinpyyntömme aitouden, mutta tämä ei salaa sitä ollenkaan. Oma teleoperaattorimme ja kaikki samassa verkossa olijat voivat tarkkailla nimipalvelinpyyntöjäni ja myös muokata kyselyitä ennen resolver-nimipalvelinta, koska liikenne on salaamatonta. Myöskin meidän selaimen sivuhistoria voi tässä vuotaa.
Tähän ratkaisuna meille on DNSCrypt, DNS over HTTPS ja DNS over TLS, jotka salaavat nimipalvelinkyselyitä päätelaitteeltasi resolver-nimipalvelimelle. Näin nimipalvelinkyselyt ovat salattu samassa verkossa olevilta käyttäjiltä ja samalla aitoutta varmistetaan, kun salatussa yhteydessä sitä pyyntöä ei voi muokata. Edelleenkin DNSSEC on hyvä asia sillä tämä varmistaa Resolver-nimipalvelimelle että nimipalvelin kyselyä ole muokattu.
HTTPS-suojaa kuitenkin verkkosivun liikennettä joten miksi salata nimipalvelinkyselyt?
Kyllä HTTPS-salaus tai SSL/TLS-salaus yleisestikin suojaa ettet joudu väärille sivuille yleensä. Tietenkään nimipalvelinpyyntöjen salaus ja aitouden tarkistus ei korvaa SSL/TLS-salattuja yhteyksiä ollenkaan. Se tuo lisäturvaa, kun internetin yleisimpiin komponentteihin tehtäsiiin hyökkäys.
Esimerkikki tapaus on suhteellisen tuorekin: https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/ . Tässä on hyökkäys tehty suoraan internetin reititykseen, jonka seurauksena saatiin ohjattua nimipalvelinliikenne hyökkääjän nimipalvelimille ja sielä nimipalvelin vastaa väärää IP-osoitetta. Tietysti sivulla on HTTPS-yhteys ja tuli SSL/TLS-varmenne varoitus, mutta useimmat käyttäjät ohittavat nämä varoitusviestit. Tässä sivuston ylläpitäjä olisi voinut suojata paremmin käyttämällä HSTS-otsikkoa, joka pakottaa selaimen TLS-varmenteen tarkistamaan eikä päästä mikäli virhe.
Toinen epäluottamus tälläisissä tekee mikäli internet-liikenteessä näin suuria hyökkäyksiä tehdään, niin esimerkiksi ihan aidonkin SSL/TLS-varmenteen on mahdollista hankkia sivustolle, jolloin käyttäjät eivät saa edes virheilmoituksia. Let’s Encrypt esimerkiksi varmistaa vain verkkotunnuksen nimipalvelimista ja mahdollistaa varmenteen hakemisen todella helposti. Mikäli verkkotunnuksella on DNSSEC, niin varmenteen haku estyy kun nimipalvelin palauttaa SERVERFAIL-virheilmoituksen kun hyökkäys on käynniss.
Yhteenveto
Lyhyt yhteenveto artikkelista:
- Nimipalvelinkyselyt ovat salaamattomia oletuksena eikä aitoutta voida resolver-nimipalvelin voi varmistaa puolestasi aitoutta.
- Nimipalvelinkyselyt voidaan salata resolver-nimipalvelimelle asti DNSCrypt, DNS over HTTPS tai DNS over TLS-menetelmillä. Samalla varmistetaan, että pyynnöt tulevat oikealta resolver-nimipalvelimelta.
- Yhdistettynä DNSSEC ja DNSCrypt, DNS over HTTPS tai DNS over TLS saadaan salattua nimipalvelinpyynnöt resolver-nimipalvelimelle ja varmistettua nimipalvelinkyselyiden aitouden.
- DNS-varmistukset tai salaukset eivät korvaa SSL/TLS-salausta mitä käytetään https-liikenteessä. Sen tarkoituksena tukea tätä salausta ja estää pääsyn verkkosivulle ennen kuin https-yhteyttä muodostetaan mikäli varmennuksissa on virheitä.