DANE - autentifikácia pomenovaných entít na základe DNS

E-maily sa prenášajú medzi servermi cez SMTP, pričom odosielateľ vyhľadá cieľový server pomocou záznamu MX a poštu prenesie cez port 25/TCP. Všetky správy sa dlho prenášali nezašifrované, hoci štandard s protokolom TLS/SSL/STARTTLS už dlho existuje na šifrovanie e-mailov aspoň na transportnej trase. Pre toto šifrovanie sú samozrejme potrebné certifikáty.

dane

Táto stránka je stále vo výstavbe. DANE umožňuje kontrolu certifikátu cieľového systému cez DNSSEC. Bohužiaľ sa neplánuje žiadne overenie vysielača. Bohužiaľ to nebude spamový filter.

Používané certifikáty

Certifikáty nie sú samy o sebe zlou vecou, ​​pretože umožňujú pomerne bezpečný prenos e-mailov, z ktorých majú obe strany úžitok:

  • Odosielateľ.
    . si môžete byť istí, že dosiahol správny cieľový server. Je to porovnateľné s prístupom do domáceho bankovníctva. Vyššie zadáte meno a certifikát musí obsahovať aj toto meno. Inak ste skončili inde
  • Príjemca.
    . môže voliteľne identifikovať počítač pomocou certifikátu odosielateľa.

Na papieri tento princíp vyzerá veľmi elegantne a vodotesne, ale nie je to tak. Je potrebné mať na pamäti niekoľko vecí:

  • Žiadne vlastné certifikáty -> náklady
    Jedným z problémov je, že aspoň príjemca musí mať „dôveryhodný certifikát“. Ak je povolený vlastný certifikát, útočník v strede môže certifikát jednoducho ukázať a bezpečnosť nie je zaručená.
  • Spoofing DNS
    Ďalej by útočník mohol jednoducho podrobiť odosielateľa inému serveru pre požiadavku MX, pre ktorú má útočník správny certifikát. Málokto si všimne, že pošta trvá „obchádzkou“, ak cieľová adresa nekontroluje odosielateľa. Príjemca musí mať tiež možnosť „skontrolovať“ odosielateľa. Falšovaniu DNS dotazov je možné zabrániť napríklad pomocou DNSSEC.
  • Dôvera CA.
    Musí sa samozrejme tiež zabezpečiť, aby si vydávajúce CA, ktorým partneri dôverujú, získali ich dôveru. Nanešťastie by to nebolo prvýkrát, čo CA nepravdivo vydala certifikát a veľa CA je v krajinách, kde si nemôžete byť istí, že vyšetrovacie orgány a tajné služby nemôžu získať certifikát na zaujímavé meno.

V tomto ohľade je TLS/SSL/STARTTLS začiatkom šifrovania komunikácie, ale iba v polovici cesty, pokiaľ partneri spoľahlivo nepreukážu svoju totožnosť.

Overenie odosielateľa a IPv6

Najmä pokiaľ ide o SPAM, s pribúdajúcimi pripojeniami IPv6 budeme mať čoraz viac problémov s klasickými zoznamami blokov. Dnes sa internet skladá z maximálne 255 * 255 * 255 * 255 adries. Dnes je to „zvládnuteľné“ a príslušné databázy a služby môžu pomerne spoľahlivo udržiavať zoznam „nežiaducich systémov“, ktoré možno rozpoznať ako odosielateľov spamu, vírusových injektorov alebo iného škodlivého softvéru.

S IPv6 je to oveľa zložitejšie. Klasické zoznamy blokov tu dosiahnu svoje limity, pretože spameri môžu pre každú poštu teoreticky použiť vlastnú adresu IP. Iste určite budú existovať príležitosti na zoskupovanie podsietí alebo podobných sietí, ale filtrovanie na úrovni IP už nebude fungovať tak ľahko a efektívne ako dnes. Filtr nevyžiadanej pošty však môže začať filtrovať až pri samotnom prenose pošty. Už je neskoro.

Jedným zo spôsobov, ako môžu spoločnosti pomôcť, je publikovať svoje servery odchádzajúcej pošty, napríklad prostredníctvom DNS. SenderID alebo SPF. Server príjemcu sa pozrie na odosielateľa prichádzajúcej pošty, dopytuje sa na „server odchádzajúcej pošty“ prostredníctvom DNS a ak sa zhoduje zdrojová adresa IP, môže tento e-mail prijať. Pre „normálneho útočníka“ je relatívne ľahké sfalšovať zdrojovú IP paketu, ale aby zhromaždil spätné pakety, musí útočník zmeniť trasy na internete. pre štátne organizácie (tajné služby atď.) by malo byť zodpovedajúcim spôsobom ľahké, ak sa dá infiltrovať týmto spôsobom.

Pokiaľ samotné DNS dotazy nie sú „zabezpečené“, odpoveď na RBL dopyt môže byť samozrejme sfalšovaná alebo zničená útočníkom. Pokiaľ RBL nie je „povinný“, ale iba voliteľný, stačí to na preskočenie šeku príjemcu.

Cieľové overenie pomocou TLS a DNSSEC

Je oveľa výhodnejšie, ak do kontroly odosielateľa zahrnieme požadované šifrovanie a podpisovanie prenosu. Zodpovedajúci návrh je popísaný v „Autentifikácii pomenovaných entít na základe RFC 6698 DNS“, ktorá v úvode tiež uvádza, že certifikáty sú pekné, ale každá „dôveryhodná“ CA môže vydať kľúč pre každé meno. To sa dá vylepšiť, ak vlastník domény napr. Zverejní informácie o certifikátoch používaných cez DNS. Aby však útočníci presne tieto informácie nezmenili, musí byť prenos DNS minimálne podpísaný. Používa sa na to DNSSEC, pričom vyššie uvedená zóna potom poskytuje informácie o podpise subzóny.

Server, ktorý komunikuje so vzdialenou stanicou prostredníctvom protokolu TLS, môže prostredníctvom protokolu DNSSEC prijímať informácie o tom, aký certifikát sa má očakávať. Nakoniec len správne zadanie správnych údajov závisí od koordinácie medzi operátorom služby a správcom DNS. Prísne vzaté, certifikát by nemusel byť vydaný ani verejnou CA, ale mohol by to byť samocert.

Je len škoda, že DNSSEC je ešte len v plienkach a že Exchange Server nemôže cez DynDNS automaticky zadávať svoje „vlastné osvedčenie“ do zóny DNS. Pravdepodobne nebude dôjsť k žiadnym dynamickým aktualizáciám položiek certifikátu v DNS, a to aj z bezpečnostných dôvodov. Vďaka systému Windows DNS už zónu zabezpečenú technológiou DNSSEC nie je možné použiť na dynamické aktualizácie.

Nastaviť DANE

DANE je v súčasnosti vždy nastavený na cieľovom systéme alebo server príjemcu môže zverejniť svoje informácie prostredníctvom DANE a odosielateľ môže, ale nemusí používať tieto informácie. Vyžadujú sa nasledujúce požiadavky.

  • Cieľová doména zabezpečená DNSSEC
    Až potom má vôbec zmysel ukladať informácie na overenie.
  • Cieľový server musí robiť protokol SSL/TLS
    Dátové pripojenie musí byť možné pomocou protokolu SSL/TLS. Až potom dostane odosielateľ certifikát od terča a bude mať podľa toho čo skontrolovať
  • Klient/odosielateľ musí byť schopný vyriešiť DNSSEC
    Hostiteľský systém musí byť samozrejme schopný vyriešiť a overiť cestu k serveru zákazníka, počnúc koreňovou zónou a registrátorom, t. J. Server DNS a prekladač musia poskytovať DNSSEC.
  • Aplikácia klient/odosielateľ musí podporovať DANE
    Nakoniec samozrejme musí samotná aplikácia chcieť používať DANE.

Napriek tomu stojí za to zverejniť informácie o použitom certifikáte. V prvej fáze to budú pravdepodobne doplnky prehliadača, ktoré využívajú pridanú hodnotu. V strednodobom horizonte proxy a reléové systémy vo firmách odbremenia používateľa od tejto práce, t. J. Poštový server nebude posielať poštu, ak prijatý certifikát nezodpovedá informáciám o certifikáte uloženým v DNS. V určitom okamihu sa môže stať štandardným vybavením operačných systémov alebo modulu TLS.

Nastavenie prebieha v niekoľkých krokoch: