DANE - автентифікація іменованих об’єктів на основі DNS

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

Цей сайт все ще будується. DANE дозволяє перевірити сертифікат цільової системи через DNSSEC. На жаль, не планується перевірка передавача. На жаль, це не буде фільтр спаму.

Сертифікати, що використовуються

Сертифікати самі по собі не є поганим, оскільки вони дозволяють досить безпечно передавати електронні листи, від яких обидві сторони виграють:

• Відправник.
  . можна бути впевненим, що він досяг правильного цільового сервера. Це можна порівняти з доступом до домашнього банкінгу. Ви вводите ім’я вище, і сертифікат також повинен містити це ім’я. Інакше ти опинився деінде
• Одержувач.
  . за бажанням може ідентифікувати комп’ютер через сертифікат відправника.

На папері цей принцип виглядає дуже елегантно та водонепроникно, але це не так. Є кілька речей, про які слід пам’ятати:

• Відсутність власних сертифікатів -> витрати
  Однією з проблем є те, що принаймні одержувач повинен мати "надійний сертифікат". Якщо дозволено самосвідчення, зловмисник посередині може просто показати сертифікат, і безпека не гарантована.
• Підробка DNS
  Крім того, зловмисник може просто підпорядкувати відправника іншому серверу для запиту MX, для якого зловмисник має правильний сертифікат. Навряд чи хтось помітить, що пошта має "об'їзд", якщо адресат не перевіряє відправника. Одержувач також повинен мати можливість "перевірити" відправника. Наприклад, DNSSEC може запобігти фальсифікації запитів DNS.
• Довіра ЦС
  Звичайно, слід також переконатися, що органи сертифікації, яким партнери довіряють, заслужили їхню довіру. На жаль, це не перший раз, коли ЦС видає помилково сертифікат, і багато ЦС перебувають у країнах, де не можна бути впевненим, що слідчі органи та спецслужби не можуть отримати сертифікат на цікаве ім’я.

У цьому відношенні 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-ідентифікація іменованих об'єктів", де у вступі також зазначено, що сертифікати є приємними, але кожен "надійний" ЦС може видати ключ для кожного імені. Це можна покращити, якщо власник домену публікує інформацію про сертифікати, що використовуються через DNS, наприклад. Однак, щоб зловмисники точно не змінили цю інформацію, передача 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.

Налаштування відбувається в кілька етапів:

---