Поліпшення конфіденційності DNS за допомогою Oblivious DoH в 1.1.1.1
Сьогодні ми оголошуємо про підтримку нового пропонованого стандарту DNS, розробленого в співавторстві з інженерами Cloudflare, Apple і Fastly, який відокремлює IP-адреси від запитів, так що жоден об'єкт не може бачити обидва одночасно. Більш того, ми зробили доступним вихідний код, так що будь-хто може спробувати ODoH або запустити свій власний сервіс ODoH!
Але спочатку трохи контексту. Система доменних імен (DNS) - це основа Інтернету, доступного для людей. Він зіставляє використовувані доменні імена, такі як cloudflare.com, з IP-адресами та іншою інформацією, необхідною для підключення до цього домену. Короткий посібник про важливість і проблеми з DNS можна прочитати в попередньому повідомленні блогу. Для цього поста досить знати, що при первісному дизайні і все ще переважному використанні DNS запити відправляються у відкритому вигляді. Це означає, що будь-хто на мережевому шляху між вашим пристроєм і перетворювачем DNS може бачити як запит, який містить бажане ім'я хоста (або веб-сайт), так і IP-адресу, що ідентифікує ваш пристрій.
Щоб захистити DNS від сторонніх і третіх осіб, IETF стандартизував шифрування DNS з використанням DNS через HTTPS (DoH) і DNS через TLS (DoT). Обидва протоколи запобігають перехопленню, перенаправленню або зміні запитів між клієнтом і перетворювачем. Клієнтська підтримка DoT і DoH зростає, вона реалізована в останніх версіях Firefox, iOS і інших. Проте, до тих пір, поки не відбудеться більш широке поширення серед інтернет-провайдерів, Cloudflare буде одним з небагатьох провайдерів, що пропонують загальнодоступну послугу DoH/DoT. Це викликало дві основні проблеми. Одна з проблем полягає в тому, що централізація DNS створює єдині точки відмови (хоча з центрами обробки даних в більш ніж 100 країнах Cloudflare завжди доступний). Інша проблема полягає в тому, що перетворювач все ще може пов'язувати всі запити з IP-адресами клієнтів.
Cloudflare прагне конфіденційності кінцевих користувачів. Користувачі нашої загальнодоступної служби розпізнавання DNS захищені суворою перевіреною політикою конфіденційності. Однак для деяких довіра Cloudflare до конфіденційної інформації про запити є перешкодою для прийняття, навіть при такій суворої політиці конфіденційності. Замість того, щоб покладатися на політику конфіденційності і аудит, що, якби ми могли дати користувачам можливість видалити цю смугу з технічними гарантіями?
Сьогодні Cloudflare і партнери запускають підтримку протоколу, який робить саме це: Oblivious DNS over HTTPS, або скорочено ODoH.
Партнери ODoH:
Ми раді запустити ODoH з декількома провідними партнерами по запуску, які в рівній мірі віддані конфіденційності.
Ключовим компонентом ODoH є проксі, не пов'язаний з цільовим перетворювачем. Сьогодні ми запускаємо ODoH з декількома провідними партнерами по проксі, включаючи PCCW, SURF і Equinix.
«ODoH - це революційно нова концепція, покликана зробити конфіденційність користувачів в центрі всього. Наше партнерство ODoH з Cloudflare дає нам хороші можливості в сфері конфіденційності і «інфраструктури Інтернету». Поряд з підвищеною безпекою і продуктивністю базової глобальної мережі PCCW, доступ до якої можна отримати за запитом через Console Connect, продуктивність проксі-серверів в нашій мережі тепер поліпшена перетворювачами Cloudflare 1.1.1.1. Ця модель вперше повністю відокремлює клієнтський проксі від перетворювачів. Це партнерство підсилює нашу нинішню увагу до конфіденційності, оскільки світ переходить до більш віддаленої моделі, а конфіденційність стає ще більш важливою функцією». - Майкл Глінн, віце-президент по цифровим автоматизованим інноваціям, PCCW Global
«Ми співпрацюємо з Cloudflare, щоб поліпшити конфіденційність користувачів за допомогою ODoH. Перехід до ODoH - це справжнє зрушення парадигми, коли конфіденційність користувачів або IP-адреса не розкриваються жодному провайдеру, що призводить до істинної конфіденційності. З запуском пілотного проекту ODoH ми приєднуємося до потужності мережі Cloudflare, щоб вирішувати завдання будь-яких користувачів по всьому світу. Перехід на ODoH - це не тільки зміна парадигми, а й підкреслення того, наскільки важлива конфіденційність для будь-яких користувачів, ніж будь-коли, особливо в 2020 році. Це перегукується з нашою основною спрямованістю і переконанням щодо конфіденційності». - Йост ван Дейк, технічний менеджер по продукції, SURF
Як працює Oblivious DNS over HTTPS (ODoH)?
ODoH - це новий протокол, що розробляється IETF. ODoH працює шляхом додавання рівня шифрування з відкритим ключем, а також мережевого проксі між клієнтами і серверами DoH, такими як 1.1.1.1. Комбінація цих двох додаткових елементів гарантує, що тільки користувач має доступ як до повідомлень DNS, так і до власної IP-адреси одночасно.
На шляху ODoH є три гравці. Дивлячись на малюнок вище, давайте почнемо з мети. Ціль розшифровує запити, зашифровані клієнтом, через проксі. Точно так само ціль шифрує відповіді і повертає їх проксі. Стандарт каже, що ціль може бути чи не бути перетворювачем (ми торкнемося цього пізніше). Проксі-сервер робить те, що повинен робити проксі, в тому сенсі, що він пересилає повідомлення між клієнтом і ціллю. Клієнт поводиться так само, як в DNS і DoH, але відрізняється тим, що шифрує запити для цілі і розшифровує відповіді цілі. Будь-який клієнт, який вирішить це зробити, може вказати бажані проксі і ціль.
Разом додані шифрування і проксування забезпечують такі гарантії:
- Ціль бачить тільки запит і IP-адресу проксі.
- Проксі-сервер не бачить повідомлень DNS і не може ідентифікувати, читати або змінювати ні запит, що відправляється клієнтом, ні відповідь, що повертається ціллю.
- Тільки передбачувана ціль може прочитати вміст запиту і дати відповідь.
Ці три гарантії покращують конфіденційність клієнтів при збереженні безпеки і цілісності DNS-запитів. Однак кожна з цих гарантій спирається на одну фундаментальну властивість - проксі-сервер і цільові сервери не вступають в змову. Поки немає змови, зловмисник домагається успіху, тільки якщо і проксі, і ціль скомпрометовані.
Один з аспектів цієї системи, який варто виділити, полягає в тому, що ціль відокремлена від рекурсивного перетворювача висхідного потоку, який виконує дозвіл DNS. На практиці ми очікуємо, що ціль буде такою ж. Фактично, 1.1.1.1 тепер одночасно і рекурсивний перетворювач, і ціль! Немає причин, по яким ціль повинна існувати окремо від будь-якого перетворювача. Якщо вони розділені, то ціль може вибирати перетворювачі і просто діяти як посередник. Пам'ятайте, що єдина реальна вимога полягає в тому, щоб проксі і ціль ніколи не вступали в змову.
Крім того, що важливо, клієнти повністю контролюють вибір проксі і цілі. Без необхідності в програмах, подібних TRR , клієнти можуть мати конфіденційність для своїх запитів на додаток до безпеки. Оскільки ціль знає тільки про проксі, ціль і будь-який висхідний перетворювач не звертають уваги на існування будь-яких клієнтських IP-адрес. Важливо відзначити, що це дає клієнтам більший контроль над своїми запитами і способами їх використання. Наприклад, клієнти можуть вибирати і змінювати свої проксі і цілі в будь-який час і з будь-якої причини!
Потік повідомлень ODoH
У ODoH буква «O» означає «забудькуватість», і ця властивість залежить від рівня шифрування самих повідомлень DNS. Це додане шифрування є «наскрізним» між клієнтом і ціллю і не залежить від шифрування на рівні з'єднання, що забезпечується TLS/HTTPS. Можна запитати, навіщо взагалі потрібно це додаткове шифрування при наявності проксі. Це пов'язано з тим, що для підтримки функцій проксі потрібно два окремих з'єднання TLS. Зокрема, проксі завершує TLS-з'єднання від клієнта і ініціює інше TLS-з'єднання з ціллю. Між цими двома підключеннями контексти повідомлень DNS інакше відображалися б у вигляді відкритого тексту! З цієї причини ODoH додатково шифрує сполучення між клієнтом і ціллю, тому проксі-сервер не має доступу до перегляду повідомлення.
Весь процес починається з клієнтів, які шифрують свій запит до цілі за допомогою HPKE. Клієнти отримують відкритий ключ цілі через DNS, де він об'єднується в запис ресурсу HTTPS і захищається DNSSEC. Коли TTL для цього ключа закінчується, клієнти запитують нову копію ключа в міру необхідності (так само, як вони зробили б для запису A/AAAA, коли закінчується TTL цього запису). Використання перевіреного DNSSEC відкритого ключа цілі гарантує, що тільки передбачувана ціль може розшифрувати запит і зашифрувати відповідь.
Клієнти передають ці зашифровані запити проксі-сервера через HTTPS-з'єднання. Після отримання проксі-сервер пересилає запит зазначеної цілі. Потім ціль розшифровує запит, створює відповідь, відправляючи запит рекурсивному перетворювачу, наприклад 1.1.1.1, а потім шифрує відповідь клієнту. Зашифрований запит від клієнта містить інкапсульований ключовий матеріал, з якого цільові об'єкти отримують симетричний ключ шифрування відповіді.
Потім ця відповідь відправляється назад на проксі, а потім пересилається клієнту. Всі комунікації проходять перевірку автентичності та конфіденційні, оскільки ці DNS-повідомлення зашифровані наскрізним шифруванням, незважаючи на те, що вони передаються по двом окремим HTTPS-з'єднанням (клієнт-проксі і проксі-ціль). Повідомлення, яке в іншому випадку є для проксі-сервера як відкритий текст, насправді є зашифрованим спотворенням.
А як щодо продуктивності? Чи повинен я торгувати продуктивністю, щоб отримати конфіденційність?
Ми провели багато вимірів, щоб з'ясувати це, і будемо робити більше в міру більш широкого розгортання ODoH. Наш початковий набір конфігурацій вимірювань охоплював міста в США, Канаді та Бразилії. Важливо відзначити, що наші виміри включають не тільки 1.1.1.1, але також 8.8.8.8 і 9.9.9.9. Повний набір вимірів поки задокументований для відкритого доступу.
У цих вимірах було важливо відокремити вартість проксування і додаткового шифрування від вартості налаштування TCP і TLS-з'єднання. Це тому, що витрати TLS і TCP в будь-якому випадку несе DoH. Отже, в нашому налаштуванні ми «підготували» виміри, встановивши з'єднання один раз і повторно використовуючи це з'єднання для всіх вимірювань. Ми зробили це як для DoH, так і для ODoH, оскільки в будь-якому випадку могла використовуватися одна і та ж стратегія.
Перше, що можна сказати з упевненістю, це те, що додаткове шифрування маргинально. Ми знаємо це, тому що випадковим чином вибрали 10 000 доменів з набору даних Tranco Million і виміряли як шифрування запису A з іншим відкритим ключем, так і його розшифровку. Додаткові витрати між проксованим запитом/відповіддю DoH і його аналогом ODoH незмінно складають менше 1 мс на 99-му процентилі.
Однак конвеєр запиту-відповіді ODoH - це набагато більше, ніж просто шифрування. Дуже корисний спосіб поглянути на вимірювання - це подивитися на діаграму сукупного розподілу. Якщо ви знайомі з цими типами діаграм, перейдіть до наступного абзацу. На відміну від більшості діаграм, де ми починаємо з осі X, з кумулятивними розподілами ми часто починаємо з осі Y.
На діаграмі нижче показано кумулятивний розподіл часу запиту/відповіді в DoH, ODoH і DoH при передачі по мережі Tor. Пунктирна горизонтальна лінія, яка починається зліва від 0,5, відповідає позначці 50%. Уздовж цієї горизонтальної лінії для будь-якої побудованої кривої частина кривої нижче пунктирною лінії становить 50% точок даних. Тепер подивимося на вісь абсцис, яка є мірою часу. Рядки, які з'являються зліва, швидші, ніж рядки праворуч. Остання важлива деталь полягає в тому, що вісь X нанесена в логарифмічному масштабі. Що це означає? Зверніть увагу, що відстань між поміченими маркерами (10x) в сукупних розподілах однакова, але «X» є показником ступеня і являє порядки величини. Отже, хоча різниця в часі між першими двома маркерами становить 9 мс,різниця між 3-м і 4-м маркерами становить 900 мс.
На цій діаграмі середня крива вимірювання ODoH. Ми також виміряли продуктивність альтернатив, які зберігали конфіденційність, наприклад, запитів DoH, переданих по мережі Tor, як показує права крива на діаграмі. (Додаткові альтернативи , що зберігають конфіденційність, відображені в технічному звіті відкритого доступу.) У порівнянні з іншими варіантами DNS, орієнтованими на конфіденційність, ODoH скорочує час запиту вдвічі або навіть більше. Цей момент важливий, оскільки конфіденційність і продуктивність рідко поєднуються один з одним, тому такі поліпшення вселяють надію!
Наведена вище діаграма також показує, що в 50% випадків запити ODoH вирішуються менш ніж за 228 мс. Тепер порівняйте середню лінію з лівою лінією, яка представляє «прямолінійний» (або нормальний) DoH без будь-яких змін. Ця ліва сюжетна лінія говорить про те, що в 50% випадків запити DoH вирішуються менш ніж за 146 мс. Якщо дивитися нижче позначки 50%, криві також говорять нам, що ½ часу, в якому різниця ніколи не перевищує 100 мс. З іншого боку, якщо подивитися на криві над відміткою 50%, це говорить про те, що ½ запитів ODoH конкурують з DoH.
Ці криві також приховують багато інформації, тому важливо поглибитися в вимірювання. На наведеній нижче діаграмі представлені три різні сукупні криві розподілу, які описують продуктивність ODoH, якщо ми вибираємо проксі і цілі по їх затримці. Це також приклад ідей, які можуть виявити вимірювання, деякі з яких суперечать здоровому глузду. Наприклад, якщо дивитися вище 0,5, ці криві кажуть, що ½ часу запиту/відповіді ODoH практично неможливо розрізнити, незалежно від вибору проксі і цілі. Тепер переведіть увагу нижче 0,5 і порівняйте дві суцільні криві з пунктирною кривою, яка представляє собою загальне середнє значення. Цей регіон передбачає, що вибір проксі-сервера з найменшою затримкою і цілі дає мінімальне поліпшення в порівнянні із середнім, але, що найбільш важливо, він показує,що вибір проксі з найменшою затримкою призводить до зниження продуктивності!
Звичайно, залишаються відкриті питання. Цей перший набір вимірів був виконаний в основному в Північній Америці. Чи змінюється продуктивність на глобальному рівні? Як це впливає на продуктивність клієнта на практиці? Ми працюємо над з'ясуванням цього факту, і цей випуск допоможе нам в цьому.
Цікаво! Чи можу я поекспериментувати з ODoH? Чи є відкритий сервіс ODoH?
Та й так! Ми відкрили вихідний код наших сумісних реалізацій ODoH в Rust, odoh-rs і Go, odoh-go , а також інтегрували цілі в Cloudflare DNS Resolver. Правильно, 1.1.1.1 готова приймати запити через ODoH.
У нас також є тестові клієнти з відкритим вихідним кодом на Rust, odoh-client-rs і Go, odoh-client-go, для демонстрації запитів ODoH. Ви також можете перевірити конфігурацію HPKE, використовувану ODoH для шифрування повідомлень до версії 1.1.1.1, безпосередньо запитавши службу:
$ dig -t type65 +dnssec @ns1.cloudflare.com odoh.cloudflare-dns.com
; <<>> DiG 9.10.6 <<>> -t type65 +dnssec @ns1.cloudflare.com odoh.cloudflare-dns.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19923
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;odoh.cloudflare-dns.com. IN TYPE65
;; ANSWER SECTION:
odoh.cloudflare-dns.com. 300 IN TYPE65 \# 108 00010000010003026832000400086810F8F96810F9F9000600202606 470000000000000000006810F8F92606470000000000000000006810 F9F98001002E002CFF0200280020000100010020ED82DBE32CCDE189 BC6C643A80B5FAFF82548D21601C613408BACAAE6467B30A
odoh.cloudflare-dns.com. 300 IN RRSIG TYPE65 13 3 300 20201119163629 20201117143629 34505 odoh.cloudflare-dns.com. yny5+ApxPSO6Q4aegv09ZnBmPiXxDEnX5Xv21TAchxbxt1VhqlHpb5Oc 8yQPNGXb0fb+NyibmHlvTXjphYjcPA==
;; Query time: 21 msec
;; SERVER: 173.245.58.100#53(173.245.58.100)
;; WHEN: Wed Nov 18 07:36:29 PST 2020
;; MSG SIZE rcvd: 291Ми працюємо над додаванням ODoH до існуючих перетворювачів заглушок, таким як cloudflared. Якщо ви зацікавлені в додаванні підтримки для клієнта або при виявленні помилок в реалізації, напишіть нам за адресою ask-research@cloudflare.com! Оголошення про специфікації ODoH і сервер будуть відправлятися в список розсилки IETF DPRIVE. Ви можете підписатися і стежити за оголошеннями і обговореннями специфікації тут.
Ми маємо намір просувати його в IETF і вже спостерігаємо інтерес з боку постачальників клієнтів. Ерік Рескорла, технічний директор Firefox, говорить:
Oblivious DoH - відмінне доповнення до безпечної екосистеми DNS. Ми раді бачити, що він починає набирати обертів, і з нетерпінням чекаємо можливості поекспериментувати з ним в Firefox.
Ми сподіваємося, що до нас приєднаються і інші оператори, які забезпечать підтримку протоколу, запустивши проксі-сервери або цільові об'єкти, і ми сподіваємося, що підтримка клієнтів буде рости в міру збільшення доступної інфраструктури.
Протокол ODoH є практичним підходом до підвищення конфіденційності користувачів і спрямований на поліпшення загального прийняття зашифрованих протоколів DNS без шкоди для продуктивності і зручності роботи користувачів в Інтернеті.
Подяки
Марек Вавруша і Анбанг Вен зіграли важливу роль в отриманні перетворювачем 1.1.1.1 підтримки ODoH. Кріс Вуд і Пітер Ву допомогли підготувати і протестувати бібліотеки ODoH. Автори проекту IETF для ODoH - Ерік Кіннер, Патрік Макманус, Томмі Полі і Крістофер Вуд. Сам ODoH черпав натхнення з роботи Шмітта і ін. "Oblivious DNS: Practical Privacy for DNS Queries" опублікованого в PoPETs 2019.
Переклад статті:
blog.cloudflare.com