Довести право на імʼя хоста без сертифіката

Будь-який продукт, який дозволяє клієнтові вписати імʼя хоста й далі перевіряє його щохвилини, збудував дві речі. Перша це моніторинг. Друга це розподілений генератор запитів, спрямований куди завгодно на смак клієнта, з назвою вашої компанії в user agent і платіжною адресою вашого клієнта позаду.

Звичне заперечення полягає в тому, що ціль має публічну адресу, тож трафік їй усе одно міг би слати будь-хто. Це правда, і це не про те. Публічна адреса не є дозволом когось вимірювати, а «будь-хто міг би» не є захистом, який переживає першу скаргу на зловживання, надто коли трафік періодичний, тривалий і походить із упізнаваної комерційної платформи.

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

Два методи, які доводять різні речі

Є два практичні способи довести, що імʼя належить вам, і варто чітко сказати, що вони не рівноцінні.

Запис DNS TXT доводить контроль над зоною. Хто може покласти туди значення, той вирішує, куди вказує імʼя, а це найсильніше твердження про імʼя, яке взагалі існує.

Файл на вебсервері доводить контроль над машиною, на яку імʼя зараз розвʼязується. Це слабше: на спільному хостингу створити такий файл може більше людей, ніж може редагувати зону. Це також значно досяжніше для клієнта, який має сервер, але не має доступу до DNS-провайдера свого роботодавця.

Це та сама пара компромісів, яку роблять центри сертифікації двома своїми поширеними типами challenge, і висновок той самий: пропонуйте обидва, записуйте, який було використано, і не вдавайте, що вони важать однаково.

Форма challenge

Запис TXT кладеться під власною міткою, а не на самому домені. Це не охайність. Запис на вершині домену приземляється поруч із поштовими політиками клієнта, де кожен додатковий рядок штовхає відповідь ближче до розміру, на якому в резолверів починається кепський день, і де чиєсь прибирання «старих записів TXT» прибере його без злого наміру. Під власною міткою він стоїть окремо.

Файл живе за зарезервованим шляхом, з токеном як назвою файла, і містить токен і нічого більше.

Сам токен це тридцять два шістнадцяткові символи, тобто сто двадцять вісім бітів. Це не таємниця й не ключ: він лежатиме в публічному DNS або на публічному вебсервері. Чим він має бути, так це невгадуваним, бо той, хто вміє передбачити чинний токен, може привласнити чуже імʼя, поклавши токен на власний сервер першим. Шістнадцяткові символи в нижньому регістрі роблять його безпечним для запису DNS, безпечним в URL і вільним від знаків, які можна неправильно прочитати, коли клієнт переписує його рукою.

Одне структурне правило: challenge виписує рівно один шматок коду, і результат їде разом із запитом до того, хто виконує перевірку. Якби обидві сторони знали префікс незалежно, настав би день, коли панель показує одну мітку, а перевіряльник шукає іншу, і в підсумку зʼявляється повідомлення «запису немає» про запис, який є. Немає нічого дорожчого для підтримки, ніж правильна відповідь на питання, якого ніхто не ставив.

Чому забирає саме агент

Це рішення, на якому висить решта.

Платформа не розвʼязує імені й не забирає файла. Якби робила, наша власна інфраструктура зʼєднувалася б з іменем, яке вписав користувач, а це підробка запиту на боці сервера з полем форми як поверхнею атаки. Класичним наслідком є запит до endpoint хмарних метаданих зсередини нашої власної мережі, зроблений нами, на замовлення.

Натомість це робить власний агент клієнта: той самий агент, який далі виконуватиме перевірки, розташований усередині власної мережі клієнта і зʼєднується лише назовні. Збрехати про результат нічого не дає, бо нагородою є дозвіл вимірювати те, до чого агент і так уже міг дотягнутися. Перевірку виконує та сторона, яка вже має доступ, і це єдина конструкція, в якій зникає стимул шахраювати.

Є наслідок, який варто сказати вголос, бо він має вигляд відсутнього запобіжника. Настанови для такої можливості зазвичай кажуть блокувати приватні діапазони, петлю, link-local і адреси метаданих. Те правило належить розміщеним у нас пробам, тобто точкам вимірювання, якими керуємо ми і які стоять у нашій мережі. Для агента всередині власної мережі клієнта приватні адреси є нормальним випадком: його гіпервізор, його комутатор, його сховище. Заблокувати їх означало б вимкнути єдине джерело вимірювань рівно для тієї ситуації, заради якої воно існує.

Спільним для обох шляхів є одна функція, яка вирішує, які адреси дозволені. Якби перевірка й вимірювання мали кожне власний список, настав би день, коли вони розійшлися б, і того дня одне з них стає обхідним шляхом навколо іншого.

Відмова на змішаних відповідях

Імʼя може розвʼязуватися на кілька адрес, і вони не мусять бути однаково прийнятними.

Якщо імʼя відповідає і публічною адресою клієнта, і endpoint метаданих, то кожне виконання є новим жеребом. Девʼять запусків вимірюють публічну адресу, а десятий говорить із чимось зовсім іншим. Тож кількість прийнятних відповідей не несе жодної інформації: одна заборонена адреса в наборі робить усе імʼя непридатним, і клієнтові кажуть, яка саме це була адреса, бо відмова, з якою він нічого не може зробити, є просто повідомленням про помилку.

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

Деталі, які дізнаєшся лише в роботі

Три з них вийшли з побудови перевіряльника; четверта є проєктним рішенням, яке стоїть поруч із ними.

Порівнюйте на «входження», а не на рівність. DNS-провайдер має право подавати значення TXT у лапках, а деякі панелі керування додають лапки, які потім самі ж і зрізають у власному показі. Токен довгий і непрозорий: він там або є, або його немає, а вимога точного збігу карає лише тих клієнтів, які зробили все правильно.

Надсилайте імʼя в заголовку host і в імені сервера TLS. Зʼєднання йде на адресу, яка вже пройшла перевірку політикою, але вебсерверові з кількома сайтами треба сказати, про який саме йдеться. Без обох клієнт із правильним налаштуванням не проходить перевірку, бо йому віддали чийсь інший типовий сайт.

Дозволяйте рівно одне перенаправлення. Вебсервер, який штовхає все на HTTPS, є нормою, і відмова від перенаправлення завалила б половину інтернету. Дозволити багато означало б, що доказ опиниться зовсім деінде. Один крок, і лише на той самий хост.

Не вимагайте HTTPS для файлового challenge. Доказом є токен. Сертифікат нічого до нього не додає, а вимога сертифіката перетворює перевірку права власності на перевірку сертифіката, а це інше питання з іншими режимами відмови. Це ті самі міркування, що стоять за типом challenge на звичайному HTTP у видачі сертифікатів. Зауважте, що це типове значення стосується саме перевірки права: коли вимірюваною річчю є сама схема, вгадування дало б зелений вимір чогось іншого, ніж налаштував клієнт, і там правильна поведінка це відмовити.

Доказ спливає, бо домени змінюють власника

Перевірене імʼя не має лишатися перевіреним назавжди, і причина не в параної щодо наших власних записів.

Домени змінюють власника, нікого не попереджаючи. Клієнт дає реєстрації спливти, хтось інший її підбирає, і з тієї миті ми щохвилини вимірюємо машину незнайомця, а до розкладу причеплено імʼя нашого клієнта. Ніхто в тому ланцюжку не зробив нічого поганого, і результат усе одно неприйнятний.

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

Спроби обмежено однією на шість годин, і це не привʼязано до інтервалу моніторингу. Перевірка права не є виміром: вона нічого не каже про доступність, їй немає місця в показнику безвідмовності, а частіші запити лише створюють трафік до DNS клієнта. Шість годин упродовж чотирнадцяти днів це понад пʼятдесят спроб, і це перетворює «спливло» на справжній сигнал, а не на невдачу.

Стани, які з цього виходять, це pending, verified, expiring, expired і revoked, і один із них не є брамою. «Expiring» існує, щоб інтерфейс міг когось попередити; доказ, що спливає через десять днів, сьогодні чинний, і перевірки далі йдуть. Трактувати його як окремий стан-браму означало б забрати в клієнта моніторинг того дня, коли нічого не змінилося.

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

Що ми записали б

1. 01Вирішіть, що доводить challenge, контроль над зоною чи контроль над машиною, і збережіть, який саме було використано.
2. 02Кладіть challenge під власною міткою, ніколи на вершину домену поруч із чиїмись поштовими записами.
3. 03Зробіть перевіряльником ту сторону, яка вже має доступ. Якщо ваша платформа забирає надане користувачем імʼя, ви збудували можливість підробки запитів.
4. 04Одна політика адрес для перевірки права й для вимірювання. Два списки стають двома поведінками.
5. 05Відмовляйте на змішаних відповідях, і називайте у відмові адресу, яка завинила.
6. 06Дайте доказові строк спливу, і починайте поновлення задовго до нього, бо відмова, від якої ви бережетеся, за природою є тихою.

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

З роботи над моніторингом у Provibr. Споріднене питання вимірювання без дотику, і скільки байтів перевірці дозволено надіслати, розглянуто в чому сканер має слати нуль байтів; те, як агент вирішує, яку з кількох точок вимірювання використати, описано в як агент обирає правильний периферійний вузол.