Я просто поцікавився. Ми використовуємо безліч сертифікатів SSL. Сьогодні ми майже виключно використовуємо леценкрипт (спасибі!). Суть цих сертифікатів полягає в тому, що підтвердження права власності на доменні імена на сертифікаті походить від можливості керувати або записами DNS, або веб-сайтом під цими доменами. Доказ DNS походить від додавання ключа (наданого letsencrypt) як TXT-запису до DNS.

Отже, ЯКЩО це достатньо доказів, щоб можна було змінити записи DNS для домену, чому б не використовувати сертифікати самопідписаних із відбитками пальців у DNS?

Я б сказав, що це дає таку саму довіру, що і процедура Detsencrypt на основі DNS:

1. Створіть CA, який підписався з власним підписом (просто виконайте кроки різних інструкцій)
2. Створіть сертифікат для деяких доменів
3. Підпишіть сертифікат з кроку 2 з КА з кроку 1. Тепер у вас є базовий сертифікат, підписаний не довіреним ЦА
4. Додати TXT (або виділений) запис у DNS кожного з доменів, зазначаючи: ми підписали сертифікат цього домену з цим CA. Як-от: "CA = -відбиток CA-"
5. Веб-браузер завантажує сертифікат і перевіряє його, порівнюючи відбиток пальців сертифіката CA / CA з даними в DNS для даного домену.

Це дозволило б створити довірені сертифікати самопідписання без втручання сторонніх осіб того ж рівня довіри, що і будь-який базовий сертифікат SSL. Поки у вас є доступ до DNS, ваш сертифікат дійсний. Можна навіть додати деякі DNSSEC, такі як шифрування, зробити хеш із CA плюс запис SOA, щоб переконатися, що довіра зникає при зміні запису DNS.

Це було розглянуто раніше?

Джемер

Базова інфраструктура, яка зробила б це можливим, існує і називається DNS, заснована на DNS, ідентифікація іменованих організацій та визначена в RFC6698 . Він працює за допомогою TLSAзапису ресурсів, який вказує сертифікат або його відкритий ключ кінцевого об'єкта або одного з його ЦТ у ланцюзі (насправді існує чотири різних типи, детальну інформацію див. У RFC).

Усиновлення

Однак, DANE ще не бачив широкого прийняття. VeriSign стежить за прийняттям DNSSEC і DANE і відстежує його зростання з часом :

Для порівняння, за версією VeriSign, існує близько 2,7 мільйонів DNS-зон, тобто це означає, що трохи більше 1% усіх зон мають принаймні один запис TLSA.

Я не можу дати жодної авторитетної відповіді, чому ДАНЕ, але ось мої міркування:

DANE страждає від тієї ж проблеми, що і списки відкликання сертифікатів (CRL) та протокол про статус онлайн-сертифіката (OCSP). Для перевірки дійсності представленого сертифіката необхідно звернутися до третьої особи. Ханно Бёк дає хороший огляд , чому це є великою проблемою на практиці. Це зводиться до питання, що робити, коли ви не можете отримати третю сторону. Постачальники веб-переглядачів у цьому випадку вирішили відмовитись (він же дозволив), що зробило все це безглуздо, і Chrome врешті-решт вирішив відключити OCSP у 2012 році.

DNSSEC

Можливо, DNS пропонує набагато кращу доступність, ніж сервери CRL та OCSP ЦО, але це все ще робить неможливою перевірку в режимі офлайн. Крім того, DANE слід використовувати лише спільно з DNSSEC. Оскільки звичайний DNS працює над несанкціонованим UDP, він досить схильний до підробки, атак MITM тощо. Прийняття DNSSEC набагато краще, ніж прийняття DANE, але все ще далеко не всюдисуще.

І з DNSSEC ми знову стикаємося з проблемою непрацездатності. Наскільки мені відомо, жодна основна операційна система сервера / клієнта за замовчуванням не забезпечує перевірку DNSSEC-рішення.

Тоді також є питання про скасування. DNSSEC не має механізму відкликання, а замість цього покладається на недовговічні ключі.

Підтримка програмного забезпечення

Все програмне забезпечення, що бере участь, має реалізувати підтримку DANE.

Теоретично ви можете подумати, що це буде завданням бібліотек криптовалют, а розробникам додатків не доведеться багато робити, але факт полягає в тому, що криптографічні бібліотеки, як правило, забезпечують лише примітиви, а додатки самі повинні робити багато конфігурації та налаштування. (і, на жаль, існує багато способів виправити щось неправильно).

Я не знаю, що будь-який великий веб-сервер (наприклад, Apache або nginx), наприклад, реалізував DANE або планує це зробити. Тут важливе значення мають веб-сервери, оскільки все більше речей будується на веб-технологіях, і тому вони часто є першими, де все реалізовується.

Якщо ми порівняємо CRL, OCSP та OCSP Stapling для порівняння, ми можемо зробити висновок про те, як піде історія прийняття DANE. Тільки деякі програми, які використовують OpenSSL, libnss, GnuTLS тощо, підтримують ці функції. Минуло певний час, щоб підтримати його велике програмне забезпечення, наприклад Apache або nginx, і знову посилаючись на статтю Hanno Böck, вони помилилися, і їх реалізація виявилася хибною. Інші великі програмні проекти, такі як Postfix або Dovecot , не підтримують OCSPі мають дуже обмежений функціонал CRL, в основному вказуючи на файл у файловій системі (який не обов'язково перечитувати регулярно, тому вам доведеться перезавантажувати сервер вручну тощо). Майте на увазі, що це проекти, які часто використовують TLS. Тоді ви можете почати дивитися на речі, де TLS набагато рідше, наприклад PostgreSQL / MySQL, і, можливо, вони пропонують CRL в кращому випадку.

Тому я навіть не використовую сучасні веб-сервери, і більшість інших програм навіть не має можливості впроваджувати OCSP та CRL, удачі з вашим 5-річним корпоративним додатком чи пристроєм.

Потенційні програми

То де б ви могли насправді використовувати DANE? Поки що не в загальному Інтернеті. Якщо ви керуєте сервером і клієнтом, можливо, це є можливим варіантом, але в цьому випадку ви часто можете вдатися до прикріплення відкритого ключа.

У поштовому просторі DANE отримує деяку тягу, тому що SMTP довгий час не мав жодного аутентифікованого шифрування транспорту. SMTP-сервери іноді використовували TLS між собою, але не перевіряли, що імена в сертифікатах насправді відповідають, тепер вони починають перевіряти це через DANE.

Різні типи процедур перевірки сертифікатів

У звичайних сертифікатах, що підписуються CA, існує кілька рівнів перевірки сертифікатів:

• Перевірка домену (DV) Підтверджується
  лише право власності на доменне ім'я, лише доменне ім’я відображається як "Тема" у сертифікаті
• Перевірка організації (OV)
  Доменне ім'я та ім'я власника підтверджено, ім'я домену та власник вказано як "Тема" у сертифікаті
• Розширена перевірка (EV)
  Більш сувора перевірка сутності власника, доменне ім’я та ім'я власника показують у сертифікаті як "Тема", зелену смугу з ім'ям власника

Процес, який ви описуєте та пропонуєте замінити, стосується лише найнижчого рівня, Валідація домену (DV).

DV - це рівень, на якому перевірка автентичності є відносно простою, як, наприклад, те, що зробив LetsEncrypt, і забезпечує аналогічний рівень довіри, як і DNS, якщо він буде використаний як єдине джерело для якоря довіри (наслідки UI, cert, можливо, довіряти, але містити додаткові дані, які ні в якому разі не підтверджуються).

Аутентифікація іменованих організацій на основі DNS (DANE)

DANE будується на базі DNSSEC (оскільки автентичність даних DNS має вирішальне значення) для публікації інформації про довіру до довіри для клієнтів TLS у DNS.

Він використовує TLSAтип RR і може бути використаний для ідентифікації або сертифікату, або відкритого ключа ( селектора ) або кінцевого об'єкта, або ЦС, з або без також необхідності регулярної перевірки ланцюга сертифікатів для успіху ( використання cert ) та способу cert / ключові дані представлені в записі ( відповідність типу ).

Ім'я TLSAвласника запису має префікс, який вказує порт і протокол (наприклад _443._tcp), а RData вказує на cert usage, selectorа також matching typeдодатки до даних cert / key, що відповідають , і режими. Особливості цих параметрів див. У розділі 2.1 RFC6698 .

Наприклад, TLSAзапис може виглядати так:

_443._tcp.www.example.com. IN TLSA  2 0 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971

У режимах використання 2або 3(вказує на використання лише якоря довіри TLSA) клієнт, що обізнаний з DANE, приймає сертифікат, який не підписується довіреним ЦА, але відповідає TLSAзапису.
Це концептуально те саме, що ви пропонуєте у своєму запитанні.

Улов? Клієнтів, що обізнані з DANE, в даний час більш-менш немає, одна з проблем полягає в тому, що сам DNSSEC не настільки широко розгорнутий (особливо перевірка на клієнтській машині), як те, що, ймовірно, потрібно для зльоту DANE. Ймовірно, є певна проблема з курячими яйцями, враховуючи, що DANE - це один із перших потенційно великих випадків використання, які покладаються на автентифіковані дані DNS.

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

Це можна було зробити. Це було розглянуто. Це все ще могло статися, але руху не було багато.