Tegelikult pole selge, kas DNSSEC on "see, mida me tahame".

Praegu on veebisaidi sertifitseerimine, st kuidas veebibrauser tagab, et see räägib õige saidiga (kui kasutate HTTPS-i ) tehakse digitaalsertifikaatidega, mis on välja antud umbes sajal juursertifitseerimisasutusel. Juurdepääs-CA on üksused, kes otsustasid hakata tegelema sertifikaatide väljaandmisega ning saja või enam teeb eriliseks see, et nad sõlmisid Microsofti / Apple / Mozilla / Google'iga lepingu, et lisada oma avalik võti usaldusväärsesse "iga brauseri (või operatsioonisüsteemi) pood. See tehing sisaldab palju legalistlikke võlusid ja kindlustusi.

Kuigi seda kritiseeritakse sageli läbipaistmatuse, üksikute sertifikaatide avaliku maksumuse ja mõne hästi avalikustatud eksituse (otsingu „Comodo“ ja „DigiNotar“) tõttu, on PKI-süsteem kipub majanduslikus mõttes töötama: kommertssaidid kasutavad neid ja CA-d rünnatakse väga harva (enamik rünnakuid seisneb selles, et kergeusklikku kasutajat õhutatakse ignoreerima hirmutavaid hoiatusi, mida brauser annab, kui leiab sertifikaatidest midagi ebamäärast. selle asemel, et minna vaeva olemasoleva CA õõnestamisega). Siis on suhteliselt vähe stiimuleid asjade muutmiseks (see tähendab, et on palju inimesi, kes eelistaksid erinevatel põhjustel mõnda muud süsteemi, kuid lõpuks otsustavad need asjad need, kes selle eest maksavad).

DNSSEC seisneb nende juur-CA väljavõtmises tsüklist ja selle asemel annab sertifitseerimisvolituse DNS-i hooldavatele inimestele (kaardistamine serveri nimedest IP-aadressideni) sellisel viisil et need kaks struktuuri oleksid omavahel seotud: domeeninime pärimine (mõistega "alamdomeen") liidetakse PKI pärandiga (mõistega "vahepealne CA").

On ebaselge, kas uued üürnikud oleksid CA-s äritegevuses varasemast pädevamad; nagu ma ütlesin, töötab tegelik süsteem juba üsna hästi ja sertifitseerimine pole sama käsitöö nagu nimede kaardistamine aadressidele. Samuti pole selge, kas selline võimude koondamine on tõesti hea. Suurte mängijate jaoks ei muudaks see midagi: Verisign-the-CA ja Verisign-the-registripidaja on mõlemad Verisign.

Asjade tehnilisest küljest pakub DNSSEC sertifikaatide lihtsat levitamist (aka "allkirjastatud" identiteetide sidumine avalike võtmetega ") DNS-süsteemi kaudu, kuid see pole probleem, mida oleks vaja lahendada: praegu saadab ükskõik milline SSL / TLS-server õnnelikult oma sertifikaadiketi osana algsest käepigistusest ja see töötab hästi.

Arvestades ebakindlust DNSSEC-i headuse osas ja olemasolevate PKI-ga räigete probleemide puudumist, pole ime, et suurettevõtted peavad juurutamist kiireloomuliseks. Paneme kõigepealt tööle IPv6.

Nagu allpool toodud kommentaarid näitavad, on DNSSEC-il DNS-i teabe autentimiseks mingi väärtus ise , mis blokeerib DNS-i mürgituse. DNS-i mürgitamine on lihtne rünnak keskel ründamiseks, kuid oleks vale uskuda, et see lahendab MiTM-i probleemid; see muudab ründaja asjad lihtsalt natuke keerulisemaks (nt ründaja peab kasutama WiFI-ananassi selle asemel, et lihtsalt olemasolevas WiFi-levialas auku kuritarvitada). Garantiide saamine nime vastavusse viimiseks antud IP-aadressiga ei vii teid kaugele, kui te ei saa teada, kas antud pakett pärineb tõesti selle päisesse kirjutatud IP-aadressist.

Mõlemal juhul on see ei paku suurt lisaväärtust suurtele serveritele ja see on piisav nende vastumeelsuse selgitamiseks.

DNSSEC-iga on valesti ainult see, et see on uus, DNS on (ilmselgelt) oluline ja inimesed ei soovi oma DNS-i seadistustega jamada. Kui teie DNSSEC-i juurutamine läheb valesti, võite kaotada kogu oma Interneti-kohaloleku.

Miks soovite DNS-i otsinguid autentida, lugege seda artiklit selle kohta, kuidas suurepärane tulemüür lekib väljaspool Hiinat asuvatele kasutajatele:

http://www.sigcomm.org/sites/default/files/ccr/papers/2012/juuli/2317307-2317311.pdf

See pole nii lihtsalt Hiina, kes tegeleb DNS-iga, võib igaüks, kellel on juurdepääs kliendi, kliendi lahendaja või lahendaja ja teie DNS-serverite vahelisele liiklusele, muuta ka vastuseid.

Veebisaitide sertifikaadid on vaid väike osa puzzle siin.

8 aastat hiljem :

Pean järeldama, et nad teavad DNSSEC-ist midagi halba, mis kaalub üles selle pakutavad eelised.

Ei pruugi. Nii nagu mis tahes muu tehnoloogia puhul, on ka küsimus milliseid stiimuleid kaasatud sidusrühmad pakuvad? . Kui vaatate ICANNi DNSSEC-i aruannet, näete, et peaaegu kõik tippdomeenid toetavad praegu DNSSEC-i.

Miks tarbijad seda ei kasuta? Noh, sellele pole ka lihtne vastata. Üldiselt, kui te ei soovi oma nimeserverite käivitamisega vaeva näha, peate mõne funktsiooni, näiteks DNSSECi eest hoolitsema registripidajast. Chungi jt uuring. 2017. aastal [1] näitas, et "20 parimast registripidajast ainult kolm toetavad DNSSEC-i, kui nad on DNS-operaatorid". Isegi kui teie nimeserver on DNSSEC-i kasutamiseks õigesti konfigureeritud, ei ole mingit garantiid, et kasutajad kasutaksid (rekursiivseid) lahendajaid, mis on DNSSEC-teadlikud ja nõuetekohaselt kontrollivad DNSSEC-i kirjeid [2].

Lõpptulemusena on halb turvalisuse kasutatavus - kasutajad on potentsiaalsetele lapsendajatele tõenäoliselt veel üks negatiivne stiimul. Võrreldes TLS-iga, kus kehtetute sertifikaatide korral saate otse brauseris hoiatusi ja vigu, pole DNSSEC-ile visuaalset viidet (saate kontrollida, kas veebisait on allkirjastatud või kas teie lahendaja kinnitab DNSSEC-i saidil https: //internet.nl/).

Kogu loole veel ühe pöörde andmiseks soovivad mõned osapooled mõnikord DNSSEC-i puudumist. Näiteks DNS-i mürgitamine avab ukse domeeni teisena esinemiseks, mis võib anda teile ka domeeni valideerimise (DV) sertifikaadi [3], mis võimaldab praktiliselt võltsida seaduslikku üksust isegi kehtiva sertifikaadiga (aadressiribal roheline tabalukk). Teine näide on tr TLD, mis ei toeta DNSSEC-i; nüüd kombineerige see sellega, kuidas Türgi valitsus kord kuritarvitas DNS-i tsensuuri jaoks, et saaksite teha oma järeldused.

[...] ja et saate käia DNSSEC-i kirjetes ja leiate kõik oma domeenis olevad kirjed.

NSEC3 puhul pole see enam nii.

Värskenda:

unustasin mainida RFC 3833, mis loetleb lisaks DNS-i turvaohtudele ka DNSSECi nõrkusi:

• DNSSEC-i on keeruline rakendada.
• DNSSEC suurendab oluliselt DNS-i vastuspaketid.
• DNSSEC-i vastuste valideerimine suurendab lahendaja töökoormust.
• Sarnaselt DNS-ile on ka DNSSEC-i usalduse mudel peaaegu täielikult hierarhiline.
• Võtmete liigutamine root on tõesti raske.
• DNSSEC loob nõude sünkroniseerimiseks vaba ajaga.
• Metsamärkide võimalik olemasolu tsoonis muudab autentsuse tõkestamise mehhanismi märkimisväärselt keerulisemaks.

[1] Chung, T., Levin, D., Van Rijswijk-Deij, R., Maggs, BM, Wilson, C., Choffnes, D., & Mislove, A. ( 2017). Registripidajate rolli mõistmine DNSSEC-i juurutamisel. ACM SIGCOMM Interneti-mõõtmise konverentsi, IMC osa F1319 (juuli), 369–383. https://doi.org/10.1145/3131365.3131373

[2] Chung, T., Van Rijswijk-Deij, R., Chandrasekaran, B., Choffnes, D. , Levin, D., Maggs, BM, Mislove, A., & Wilson, C. (2017). DNSSEC-i ökosüsteemi piki- ja otsvaade. USENIXi 26. turvalisuse sümpoosioni toimetised, 1307–1322.

[3] Schwittmann, L., Wander, M., & Weis, T. (2019). Domeeni teisena esinemine on teostatav: CA domeeni valideerimise haavatavuste uuring. Toimetised - 4. IEEE Euroopa turvalisuse ja privaatsuse sümpoosion, EURO S ja P 2019, 544–559. https://doi.org/10.1109/EuroSP.2019.00046