DANE - автентикација заснована на DNS на именувани субјекти

Пораките се пренесуваат помеѓу серверите преку SMTP, при што испраќачот го наоѓа дестинацискиот сервер користејќи го записот MX и ја пренесува поштата преку портата 25/TCP. Долго време, сите пораки генерално се пренесуваа нешифрирани, иако веќе подолг период постои стандард со TLS/SSL/STARTTLS за криптирање пошта барем на патот за транспорт. Секако се потребни сертификати за оваа криптирање.

именувани

Оваа страница сè уште е во фаза на изградба. DANE дозволува да се провери сертификатот за целниот систем преку DNSSEC. За жал, не е предвидена верификација на предавателот. За жал, тоа нема да биде филтер за несакана пошта.

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

Сертификатите не се лоша работа само по себе, бидејќи овозможуваат прилично безбеден пренос на е-пошта од кој имаат корист обете страни:

  • Испраќачот.
    . може да биде сигурен дека го достигнал точниот целен сервер. Ова е споредливо со пристапот до банкарството во вашиот дом. Внесувате име погоре и сертификатот мора да го содржи и ова име. Инаку завршивте на друго место
  • Примател.
    . може по избор да го идентификува компјутерот преку сертификатот на испраќачот.

На хартија, овој принцип изгледа многу елегантно и водоотпорно, но не е така. Постојат неколку работи што треба да ги имате предвид:

  • Без само-сертификати -> трошоци
    Еден проблем тука е што барем примателот мора да има „доверлив сертификат“. Ако е дозволено само-сертификат, напаѓачот во средина може едноставно да покаже сертификат и безбедноста не е загарантирана.
  • DNS измама
    Понатаму, напаѓачот може едноставно да го потчини испраќачот на друг сервер за MX барање за кое напаѓачот има точен сертификат. Тешко дека некој ќе забележи дека поштата зазема „заобиколен пат“ ако дестинацијата не го провери испраќачот. Примачот исто така мора да може да го „провери“ испраќачот. Фалсификувањето на барањата за DNS може да се спречи со DNSSEC, на пример.
  • ЦА доверба
    Се разбира, исто така, мора да се осигура дека ИС издавачите, на кои партнерите им веруваат, ја стекнале својата доверба. За жал, не би бил прв пат CA да издаде лажно уверение и многу CA се во земји каде што не можете да бидете сигурни дека истражните органи и тајните служби не можат да добијат потврда за интересно име.

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

Проверка на испраќачот и IPv6

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

Со IPv6 ова станува многу потешко. Класичните списоци со блокови ќе ги достигнат своите граници тука, бидејќи спамерите теоретски можат да користат посебна IP адреса за секоја пошта. Секако дека повторно ќе има можности за групирање на подмрежи или слично, но филтрирањето на ниво на IP веќе нема да работи лесно и ефикасно како денес. Сепак, спам филтерот може да започне да се филтрира само за време на реалното пренесување на пошта. Веќе е доцна.

Еден начин како компаниите можат да помогнат е да ги објават своите сервери за појдовни пошта, на пример, преку DNS. SenderID или SPF. Серверот примател го гледа испраќачот на дојдовна пошта, го пребарува "серверот што излегува" преку DNS и ако изворната IP-адреса се совпаѓа, тогаш може да ја прифати поштата. За „нормалниот напаѓач“ е релативно лесно да се фалсификува изворната IP на пакет, но за да ги собере пакетите за враќање, напаѓачот треба да ги смени рутите на Интернет. за владините организации (тајни служби итн.) треба да биде соодветно лесно ако целта може да се инфилтрира на овој начин.

Додека самите пребарувања на ДНС не се „обезбедени“, одговорот на барањето RBL, секако, може да биде фалсификуван или уништен од напаѓач. Сè додека RBL не е „задолжително“, туку само опционално, ова е доволно за да се прескокне проверката на примателот.

Верификација на целта со TLS и DNSSEC

Многу е поповолно ако ја вклучиме посакуваната шифрирање на транспортот и проверка на испраќачот. Соодветен предлог е опишан во „RFC 6698 DNS-based Authentication of Named Entities“, што во воведот исто така објаснува дека сертификатите се убави, но секој „доверлив“ CA може да издаде клуч за секое име. Ова може да се подобри ако сопственикот на доменот, на пр., Ги објави информациите за сертификатите што се користат преку DNS. Сепак, за да не се променат точно овие информации од страна на напаѓачите, преносот на ДНС мора барем да биде потпишан. За ова се користи DNSSEC, при што зоната погоре ги обезбедува информациите за потписот на подзоната.

Сервер кој зборува со оддалечена станица преку TLS може да добие информации преку DNSSEC за тоа кој сертификат треба да се очекува. На крајот, прашање е само на координација помеѓу операторот на услугата и администраторот на DNS за правилно внесување на точните податоци. Строго кажано, сертификатот дури и не мора да биде издаден од јавен ИС, туку може да биде само-сертификат.

Срамота е само што DNSSEC е сè уште во почетна фаза и дека серверот Exchange не може автоматски да го внесе својот „само-сертификат“ во DNS зоната преку DynDNS. Веројатно нема да има никакви динамички ажурирања на записи за сертификати во DNS од безбедносни причини. Со Windows DNS, зоната обезбедена од DNSSEC веќе не може да се користи за динамички ажурирања.

Поставете DANE

DANE моментално е секогаш поставена на целниот систем или серверот примател може да ги објави своите информации преку DANE и испраќачот може, треба, но не мора да ги користи овие информации. Потребни се следниве барања.

  • Цел на доменот обезбеден од DNSSEC
    Дури тогаш има смисла воопшто да се чуваат информации за верификација.
  • Целниот сервер мора да направи SSL/TLS
    Врската со податоците мора да биде можна преку SSL/TLS. Само тогаш испраќачот ќе добие сертификат од целта и ќе има што да провери соодветно
  • Клиентот/испраќачот мора да можат да го решат DNSSEC
    Системот домаќин мора, се разбира, да може да ја реши и потврди патеката до серверот на клиенти, почнувајќи од коренот и регистраторот, т.е. DNS серверот и резолуторот мора да обезбедат DNSSEC
  • Апликацијата за клиент/испраќач мора да ја поддржува DANE
    Конечно, се разбира, самата апликација сепак мора да сака да ја користи DANE.

Како и да е, вреди да се вложи напор да се објават информациите за користениот сертификат. Во првата фаза веројатно ќе бидат додатоци на прелистувачи кои ја користат додадената вредност. На среден рок, прокси и релејните системи кај компаниите ќе го ослободат корисникот од оваа работа, т.е. сервер за пошта нема да ја испраќа поштата ако добиениот сертификат не одговара на информациите за сертификатот зачувани во DNS. Во одреден момент може да стане стандардна опрема на оперативните системи или модулот TLS.

Поставувањето се одвива во неколку чекори: