DANE - DNS-базирано удостоверяване на именувани обекти

Пощите се предават между сървъри чрез SMTP, при което подателят намира целевия сървър, използвайки MX записа и предава пощата чрез порт 25/TCP. Дълго време всички имейли обикновено се предаваха нешифровани, въпреки че отдавна съществува стандарт с TLS/SSL/STARTTLS за криптиране на поща поне по транспортния маршрут. За това криптиране, разбира се, са необходими сертификати.

dane

Този сайт все още е в процес на изграждане. DANE позволява сертификатът на целевата система да бъде проверен чрез DNSSEC. За съжаление не се планира проверка на предавателя. За съжаление това няма да е филтър за нежелана поща.

Сертификати в употреба

Сертификатите сами по себе си не са лошо нещо, тъй като позволяват доста сигурно предаване на имейли, от които и двете страни се възползват:

  • Подателят.
    . мога да съм сигурен, че е достигнал правилния целеви сървър. Това е сравнимо с достъпа до домашното ви банкиране. Въведете име по-горе и сертификатът също трябва да съдържа това име. В противен случай сте попаднали на друго място
  • Получател.
    . по желание може да идентифицира компютъра чрез удостоверението на подателя.

На хартия този принцип изглежда много елегантен и водоустойчив, но не е така. Има няколко неща, които трябва да имате предвид:

  • Няма самосертификати -> разходи
    Един от проблемите тук е, че поне получателят трябва да има „надежден сертификат“. Ако е разрешен самосертификат, нападателят в средата може просто да покаже сертификат и сигурността не е гарантирана.
  • DNS подправяне
    Освен това нападателят може просто да подчини подателя на друг сървър за MX заявка, за която нападателят има правилен сертификат. Едва ли някой ще забележи, че пощата прави "заобиколен път", ако дестинацията не провери подателя. Получателят също трябва да може да "провери" подателя. Фалшификатите в DNS заявки могат напр. предотвратяване с DNSSEC.
  • Доверие на CA
    Разбира се, трябва също така да се гарантира, че издателите на сертификати, на които партньорите имат доверие, са спечелили тяхното доверие. За съжаление не би било за първи път CA да издава фалшиво сертификат и много CA са в страни, в които не можете да сте сигурни, че разследващите органи и тайните служби не могат да получат сертификат за интересно име.

В това отношение TLS/SSL/STARTTLS е начало за шифроване на комуникация, но само половината път, докато партньорите не докажат надеждно своята самоличност.

Проверка на подателя и IPv6

Особено когато става въпрос за СПАМ, ще имаме все повече проблеми с класическите списъци с блокове с увеличаването на IPv6 връзките. Днес Интернет се състои от максимум 255 * 255 * 255 * 255 адреса. Днес това е „управляемо“ и съответните бази данни и услуги могат доста надеждно да поддържат списък на „нежеланите системи“, които могат да бъдат разпознати като податели на спам, инжектори на вируси или друг зловреден софтуер.

С IPv6 това става много по-трудно. Класическите списъци с блокове ще достигнат своите граници тук, тъй като теоретично спамерите могат да използват свой собствен IP адрес за всяка поща. Със сигурност отново ще има възможности за създаване на подмрежи или подобни. Въпреки това, за да ги групираме толкова лесно и ефективно, колкото днес, филтрирането на ниво IP вече няма да работи. Въпреки това, филтърът за нежелана поща може да започне филтриране само по време на действителното предаване на поща. Вече е късно.

Един от начините, по които компаниите могат да помогнат, е като публикуват своите изходящи пощенски сървъри, напр. чрез DNS. SenderID или SPF. Сървърът на получателя разглежда изпращача на входяща поща, отправя запитване към „изходящия сървър“ чрез DNS и ако IP източникът съвпада, тогава той може да приеме пощата. За „нормалния атакуващ“ е сравнително лесно да се фалшифицира IP източника на даден пакет, но за да събере връщащите пакети, нападателят трябва да промени маршрутите в Интернет. за правителствени организации (тайни служби и др.) би трябвало да бъде съответно лесно, ако целта може да бъде проникната по този начин.

Докато самите DNS заявки не са "защитени", отговорът на RBL заявка може, разбира се, също да бъде фалшифициран или унищожен от нападател. Докато RBL и сътр. не е „задължително“, а само по избор, това е достатъчно, за да пропуснете проверката на получателя.

Целева проверка с TLS и DNSSEC

Много по-изгодно е, ако включим желаното транспортно криптиране и подписване в проверката на подателя. Съответно предложение е описано в "RFC 6698 DNS-базирано удостоверяване на именувани обекти", което във въведението също казва, че сертификатите са хубави, но всеки "надежден" CA може да издаде ключ за всяко име. Това може да се подобри, ако собственикът на домейна напр. информацията за използваните сертификати се публикува чрез DNS. Въпреки това, за да не се променя точно тази информация от нападателите, DNS предаването трябва поне да бъде подписано. За това се използва DNSSEC, при което зоната по-горе предоставя информация за подписването на подзоната.

Сървър, който говори с отдалечена станция чрез TLS, може да получава информация чрез DNSSEC кой сертификат да се очаква. В крайна сметка става въпрос само за координация между оператора на услугата и администратора на DNS за правилното въвеждане на правилните данни. Строго погледнато, сертификатът дори не би трябвало да се издава от публичен CA, но може да бъде самосертификат.

Жалко е, че DNSSEC е все още в началото и че сървърът на Exchange не може автоматично да въведе своя „самоудостоверение“ в DNS зоната чрез DynDNS. Вероятно няма да има динамични актуализации на записи на сертификати в DNS от съображения за сигурност. С Windows DNS зона, защитена от DNSSEC, вече не може да се използва за динамични актуализации.

Настройте DANE

Понастоящем DANE винаги е настроен на целевата система или сървърът получател може да публикува информацията си чрез DANE и подателят може, трябва, но не е задължително, да използва тази информация. Изискват се следните изисквания.

  • Целеви домейн, защитен от DNSSEC
    Едва тогава изобщо има смисъл да се съхранява информация за проверка.
  • Целевият сървър трябва да прави SSL/TLS
    Връзката за данни трябва да е възможна чрез SSL/TLS. Едва след това подателят ще получи сертификат от целта и ще има какво да провери съответно
  • Клиентът/подателят трябва да може да разреши DNSSEC
    Системата хост трябва, разбира се, да може да разрешава и проверява пътя към клиентския сървър, започвайки от коренната зона и регистратора, т.е. DNS сървърите и преобразувателите трябва да предоставят DNSSEC
  • Приложението клиент/подател трябва да поддържа DANE
    И накрая, разбира се, самото приложение трябва да иска да използва DANE.

Въпреки това си струва усилието да се публикува информацията за използвания сертификат. На първия етап вероятно ще бъдат добавки за браузър, които използват добавената стойност. В средносрочен план прокси и релейните системи в компаниите ще облекчат потребителя от тази работа, т.е. пощенският сървър не изпраща пощата, ако полученият сертификат не съответства на информацията за сертификата, съхранявана в DNS. В един момент може да се превърне в стандартното оборудване на операционните системи или модула TLS.

Настройката се извършва в няколко стъпки: