DoH (DNS через HTTPS) дуже простий. Замість того, щоб перейти на порт 53 сервера (скажімо, добре відомий 8.8.8.8) і запитати домен через пакет UDP або TCP, DoH стандартизує конструкцію GET або POST до домену HTTPS, і відповідь буде запис A та AAAA (RFC не вказує інших записів) з IP. Звичайно, у вас є більше деталей, таких як геніальне рішення в заголовку кеш-контроль збирається стати TTL. Очевидно, все наскрізне шифрування. Ви пам'ятаєте, коли в готелі ви могли пройти через DNS-протокол (як правило, необмежений) перегляд HTTP, щоб не платити за WiFi? Ну тепер, назад.
Протокол DNS схожий на верблюда. З часом він був обтяжений такою великою вагою, змушений терпіти стільки патчів, засобів і додатків, що тепер він терпляче повзе по пустелі, не вирішуючи взагалі жодної проблеми, крім того, що було розроблено. І з тієї чи іншої причини бажана безпека та/або конфіденційність ще не досягнуті. Не тому, що вона не була запропонована (насправді є десятки альтернативних або доповнюючих пропозицій одна до одної), а тому, що жодна з них не була масово прийнята. Від DNSSEC через DNS через TLS (DoT), який, як ви можете здогадатися, має продовжуватись із тим самим протоколом DNS, але з тунелем TLS (щось на зразок POP3 І SPOP3). DoT, найближче до DoH, використовує порт 853 і ефективно приховує вміст трафіку та автентифікує сервер. Цей RFC був запропонований у 2016 році. Але він не став настільки популярним, як очікувалося. Це точно не викликало ажіотажу, викликаного DoH.
До речі, є також DNS через DTLS, DNS через QUIC, DNS через TOR ... Існує навіть DoH, який повертає Json, але це спеціальна адаптація, яку Google використовує (хоча Cloudfare це також робить), потужнішу ( наприклад, це дозволяє переглядати інші записи, крім просто A або AAAA).
| Ці зображення показують, як використовувати DoH через API Google і Cloudfare, і як він повертає Json |
DNS - один із найдавніших протоколів у мережі, і це завжди було головним болем безпеки (від нападу на день народження до проблеми Камінського). Все зрозуміло, з можливістю UDP (ще легше вводити підроблені пакети ...). Катастрофа навіть без потреби в атаках, оскільки сервери можуть контролюватися урядами і таким чином перенаправляти або блокувати запити. І все абсолютно прозоро і без конфіденційності та цілісності (оскільки DNSSEC не настільки добре встановлений, як мав би бути). Ми довірили основи Інтернету протоколу, який не знає, як захистити себе технологічно, щоб рішення були масово прийняті (або воно не вимагалося, саме з тієї ж причини) і якому всілякі патчі та припарки були застосовані, щоб не порушити спадщину. Так багато Врешті-решт, пропозиція досягти безпеки стала новаторською: передайте резолюцію площині даних. І якщо цього було недостатньо, DoH змушує роздільну здатність не довіряти глобальному DNS системи, але може ігнорувати той DNS-сервер, який зазвичай надається DHCP ... так що кожна програма може вирішити через HTTPS стандартним способом.
Але це непогано, чи не так, чи не було б чудово, якби ніхто не бачив того, що ми намагаємось вирішити, і не міг це якось змінити? Замаскуйте запити та відповіді в протокол HTTPS, і нехай вас захоплює натовп у порту, який ніхто не може перерізати, 443. Більше ніяких шпигунів та обмежень. Це те, що обіцяє DoH, але чи порушує це більше, ніж виправляє?
Браузери це відзначають і вже реалізують. Це їх шанс отримати потужність не лише тому, що вони вже знають технологію HTTPS, і це їм мало коштує, алеino, оскільки вони можуть вбудувати в браузер вирішувач, який буде запитуватися за замовчуванням... Наприклад, Google більше не матиме доступу до всього, що вирішує світ завдяки своєму знаменитому 8.8.8.8, але Це дозволить розширити свій відсоток користувачів свого DNS (близько 13%) до всіх, хто використовує Chrome, що вже становить 60%. Він називає це "захищеним DNS". Ви бачили можливість вирватися з тиранії системного DNS саме там, де вирішується більшість доменів: браузер. Google вже використовує DoH у своєму додатку Intra (опублікованому під Jigsaw Operations), який точно служить для обходу блокування DNS.
Android, зі свого боку, впроваджує DNS через TLS в останній версії, хоча вони не надто публічно повідомляли про це. В даний час Cloudfare також займається DNS-бізнесом, тому відома компанія 1.1.1.1 співпрацює з Firefox, щоб бути надійним постачальником розширення. Насправді DoH у Firefox відомий як TRR (Trusted Recursive Resolver). Пообіцяйте не використовувати невелику кількість даних користувачів, які можуть їм знадобитися. Наприклад, Cloudfare погоджується видалити це подання з перших 3 октетів, які використовуються в запиті DNS. Це відправлення перших 3 октетів - це крок (із RFC), просунутий Google і OpenDNS в 2011 році, для покращення продуктивності DNS за місцем розташування IP.
| Chrome реалізує це, але поки не має інтерфейсу для його обробки. Перебувають у ньому. https://chromium-review.googlesource.com/c/chromium/src/+/1194946 |
| Firefox вже включає його, за замовчуванням вимкнено |
З іншого боку, ще однією із серйозних проблем TLS загалом є використання підроблених сертифікатів на сервері, що може дозволити порушення шифрування та шпигунства. Ця погана практика є в межах досяжності урядів, і, як це не парадоксально, слабким місцем DoH є використання TLS, особливо коли DoH розроблений саме для того, щоб уряд не міг обмежувати Інтернет через традиційні DNS. Уряд мав би просто прийти з фальшивим сертифікатом також у DoH (як це іноді роблять для інших сторінок). Але хоча DoT змушує використовувати закріплення у своєму RFC, у DoH вони навіть не рекомендують це ... Ви не передбачали цього?
| Помічено, що в DNS над TLS шпильки вказуються (в dnsprivacy.org), але те саме не зроблено в DoH. Це навіть не рекомендується. |
Щоб досягти закріплення, як і інші рішення (наприклад, неіснуючий HPKP), після рукостискання DoT TLS клієнт обчислює SPKI сертифіката на основі відкритого ключа та інших даних X.509. Це точно так само, як штифти HPKP, тільки немає першого проходу. Клієнт повинен їх знати заздалегідь і зберігати.
Це повинно зламати парадигму відомого Інтернету. Принаймні це викликає сумніви. Насправді Пол Віксі (один з батьків DNS) радикально проти цього і пропагує використання DNS через TLS замість HTTPS. Одна з причин, з якою він стверджує, полягає в тому, що (незважаючи на звукові спойлери) він нарешті дозволив собі відкрити своєрідну скриньку ПандориАналітики втратять контроль над мережею, можливість моніторингу, протоколи передачі сигналів і даних переплутані ... Слід мати на увазі, що ця модель надає ще більше потужності браузеру, а отже, і тій, що має найбільшу частку доступних на сьогодні браузерів: Google. Firefox має більш прозору політику щодо цього, хоча Cloudfare зможе отримати цікаву інформацію завдяки своєму альянсу. Як би там не було, ми занадто централізуємо DNS, який за своєю природою народився децентралізованим?
А що щодо чогось такого поширеного в безпеці, як можливість фільтрувати домени на рівні DNS? Ну, з DoH це було б неможливо, ну браузер може продовжувати відвідувати цей фішинг або команду для управління, незважаючи на те, що заблокував його в DNS компанії. Чи робимо ми шкідливу програму на користь в обмін на конфіденційність користувачів та потужність браузера?
Але DoH також відкриває нові можливості. Щоб це працювало, використовується HTTP/2-мультиплексування, що, в свою чергу, відкриває інші шляхи завдяки штовхати що дозволяє вирішити більше доменів за один раз. Крім того, це зменшує проблему витоку SNI. Чому? У HTTP/2 з'єднання використовуються повторно. При першому підключенні до веб-сайту браузер вже може знати інші сайти, що розміщені на тому самому сервері, і повторно використовувати те саме з’єднання для здійснення відвідувань. Якщо з'єднання зашифровано ... канал повторно використовується без необхідності надсилати SNI знову. Оскільки на одному сервері вже є кілька сторінок, це трапляється більшу частину часу.
Підсумовуючи: у місцевій, уважний до ваших браузерів і якщо ви спостерігаєте щось, що не збігається при вирішенні доменів у ваших системах, ви вже знаєте, куди можуть потрапити знімки; глобальний ... щоб побачити, які нові парадигми нам приносить цей протокол.