DANE - A megnevezett entitások DNS-alapú hitelesítése

A leveleket SMTP-n keresztül továbbítják a szerverek között, így a feladó az MX rekord segítségével megtalálja a célkiszolgálót, és a levelet a 25/TCP porton keresztül továbbítja. Hosszú ideig az összes levelet általában titkosítatlanul továbbították, bár a TLS/SSL/STARTTLS szabvány már régóta létezik a levelek titkosításához legalább a szállítási útvonalon. A titkosításhoz természetesen tanúsítványokra van szükség.

Ez az oldal még mindig építés alatt áll. A DANE lehetővé teszi a célrendszer tanúsítványának ellenőrzését a DNSSEC-en keresztül. Sajnos az adó ellenőrzését nem tervezik. Sajnos nem lesz spamszűrő.

Használatban lévő tanúsítványok

A tanúsítványok önmagukban nem rosszak, mivel lehetővé teszik az e-mailek meglehetősen biztonságos továbbítását, amelyek mindkét fél számára előnyösek:

• A küldő.
  . biztos lehet benne, hogy a megfelelő célszervert érte el. Ez összehasonlítható az otthoni banki hozzáféréssel. Beír egy nevet fent, és a tanúsítványnak tartalmaznia kell ezt a nevet is. Különben máshova kerültél
• Befogadó.
  . opcionálisan azonosíthatja a számítógépet a feladó tanúsítványán keresztül.

Papíron ez az elv nagyon elegánsnak és vízállónak tűnik, de nem az. Számos dolgot érdemes szem előtt tartani:

• Nincs önigazolás -> költség
  Az egyik probléma itt az, hogy legalább a címzettnek rendelkeznie kell "megbízható tanúsítvánnyal". Ha engedélyezik az önigazolást, a középen lévő támadó egyszerűen megmutathatja a tanúsítványt, és a biztonság nem garantált.
• DNS-hamisítás
  Ezenkívül a támadó egyszerűen alávetheti a küldőt egy másik szervernek egy olyan MX-kéréshez, amelyre a támadónak megfelelő tanúsítványa van. Aligha veszi észre, hogy a levél "kitérőt" tesz, ha a címzett nem ellenőrzi a küldőt. A címzettnek képesnek kell lennie a küldő "ellenőrzésére" is. A DNS-lekérdezések hamisítását például a DNSSEC segítségével lehet megakadályozni.
• CA bizalom
  Természetesen azt is garantálni kell, hogy a kibocsátó hitelesítésszolgáltatók, amelyekben a partnerek megbíznak, kiérdemelték bizalmukat. Sajnos nem ez az első alkalom, hogy egy CA hamisan állít ki tanúsítványt, és sok CA olyan országban van, ahol nem lehet biztos abban, hogy a nyomozó hatóságok és a titkosszolgálatok nem szerezhetnek igazolást egy érdekes névről.

Ebben a tekintetben a TLS/SSL/STARTTLS a kommunikáció titkosításának kezdete, de csak félúton, amíg a partnerek nem bizonyítják megbízhatóan személyazonosságukat.

Feladó ellenőrzése és IPv6

Különösen ami a SPAM-et illeti, egyre több problémánk lesz a klasszikus blokklistákkal az IPv6-kapcsolatok növekedésével. Ma az internet legfeljebb 255 * 255 * 255 * 255 címből áll. Ma ez "kezelhető", és a megfelelő adatbázisok és szolgáltatások meglehetősen megbízhatóan képesek felsorolni azokat a "nem kívánt rendszereket", amelyek felismerhetők spam, vírusinjektorok vagy más rosszindulatú programok küldőiként.

Az IPv6 segítségével ez sokkal nehezebbé válik. A klasszikus blokklisták itt elérik a korlátaikat, mivel a spamelők elméletileg minden egyes levélhez külön IP-címet használhatnak. Természetesen ismét lesz lehetőség alhálózatok vagy hasonló csoportosításra, de az IP-szintű szűrés már nem fog olyan egyszerűen és hatékonyan működni, mint manapság. A spamszűrő azonban csak a tényleges levélátvitel során kezdheti meg a szűrést. Elég késő van.

A vállalatok egyik módja az lehet, ha közzéteszik kimenő levelező szervereiket, például DNS-en keresztül. SenderID vagy SPF. A fogadó szerver megnézi a bejövő levelek küldőjét, DNS-en keresztül kérdezi a "kimenő szervert", és ha a forrás IP megegyezik, akkor elfogadhatja az e-mailt. A "normális támadó" számára viszonylag könnyű hamisítani egy csomag forrás IP-jét, de a visszatérő csomagok összegyűjtéséhez a támadónak meg kell változtatnia az útvonalat az interneten. állami szervezetek (titkosszolgálatok stb.) számára ennek megfelelően könnyűnek kell lennie, ha a célpontot ilyen módon be lehet beszivárogni.

Mindaddig, amíg maguk a DNS-lekérdezések nincsenek "biztonságban", az RBL-lekérdezésre adott választ természetesen egy támadó is meghamisíthatja vagy megsemmisítheti. Mindaddig, amíg az RBL nem "kötelező", csak opcionális, ez elegendő a címzett ellenőrzésének kihagyásához.

Célellenőrzés a TLS és a DNSSEC segítségével

Sokkal előnyösebb, ha a feladó csekkjébe belefoglaljuk a kívánt szállítási titkosítást és aláírást. A megfelelő javaslatot az "RFC 6698 DNS-alapú elnevezett entitások hitelesítése" ismerteti, amely a bevezetőben azt is kimondja, hogy a tanúsítványok szépek, de minden "megbízható" CA kiadhat kulcsot minden névhez. Ez javítható, ha a domain tulajdonosa például a DNS-en keresztül közzéteszi az alkalmazott tanúsítványokról szóló információkat. Annak érdekében azonban, hogy a támadók pontosan ne változtassák meg ezeket az információkat, a DNS-továbbítást legalább alá kell írni. Erre a DNSSEC-t használják, amikor a fenti zóna ezután információt szolgáltat az alzóna aláírásáról.

A távoli állomással TLS-n keresztül beszélő szerver DNSSEC-en keresztül információkat fogadhat arról, hogy mely tanúsítvány várható. Végül csak a szolgáltató és a DNS-rendszergazda közötti egyeztetés kérdése a helyes adatok helyes megadása. Szigorúan véve a tanúsítványt nem is kellene nyilvános CA-nak kiállítania, hanem önbizonyítvány lehet.

Csak kár, hogy a DNSSEC még mindig gyerekcipőben jár, és hogy az Exchange szerver nem tudja automatikusan beírni "önigazolását" a DNS zónába a DynDNS-en keresztül. Biztonsági okokból valószínűleg nem lesz dinamikus frissítés a tanúsítványbejegyzésekről a DNS-ben. A Windows DNS használatával a DNSSEC által biztonságos zóna már nem használható dinamikus frissítésekhez.

Állítsa be a DANE-t

A DANE jelenleg mindig a célrendszeren van felállítva, vagy a fogadó szerver közzéteheti az információkat a DANE-n keresztül, és a feladó ezeket az információkat felhasználhatja, kell, de nem muszáj. A következő követelmények szükségesek.

• Céltartomány DNSSEC által biztosított
  Csak akkor van értelme információt tárolni ellenőrzés céljából.
• A célszervernek SSL/TLS-t kell tennie
  Az adatkapcsolatnak SSL/TLS-en keresztül lehetségesnek kell lennie. A feladó csak ezután kap igazolást a céltól, és van mit ellenőriznie ennek megfelelően
• Az ügyfélnek/a feladónak képesnek kell lennie a DNSSEC feloldására
  A gazdagép rendszernek természetesen képesnek kell lennie a gyökérzónától és a regisztrátortól kezdve megoldani és ellenőrizni az ügyfélkiszolgálóhoz vezető utat, vagyis a DNS-kiszolgálónak és a megoldónak meg kell adnia a DNSSEC-t
• Az ügyfél/küldő alkalmazásnak támogatnia kell a DANE-t
  Végül természetesen magának az alkalmazásnak továbbra is a DANE-t akarja használni.

Ennek ellenére érdemes megtenni a felhasznált tanúsítvánnyal kapcsolatos információk közzétételét. Az első szakaszban valószínűleg a böngésző kiegészítői használják a hozzáadott értéket. Középtávon a vállalatok proxy- és továbbító rendszerei mentesítik a felhasználót ettől a munkától, vagyis a levelezőszerver nem küldi el a levelet, ha a kapott tanúsítvány nem egyezik meg a DNS-ben tárolt tanúsítványinformációkkal. Egy bizonyos ponton az operációs rendszerek vagy a TLS modul alapfelszereltségévé válhat.

A beállítás több lépésben történik:

---