Технически DNSCrypt по пример - Ера
Книги: "Създаване на сайтове" - "Войни на домейни". Информационна сигурност: техническо описание на TLS, тестов сървърTLS 1.3. Ресурси: LaTeX
Технически: DNSCrypt на примера на „Yandex Browser“
Хората често питат какво е DNSCrypt и защо ви е необходим. Преди известно време вече писах за DNSCrypt, във връзка с Yandex.Browser, тогава ставаше дума за поддръжка в бета версията на браузъра. Този път ще разгледаме технологията в детайли, а Yandex.Browser ще служи като пример и източник на лабораторни данни. Анализирам пакети в Wireshark, за който написах малък анализатор на DNSCrypt (в терминологията на Wireshark това е дисектор в Lua; не можах да идентифицирам обикновения анализатор на DNSCrypt в Wireshark).
DNSCrypt. Протоколът може да използва TCP и UDP като транспорт. На практика UDP се предпочита, ако е наличен, но спецификацията стриктно изисква TCP поддръжка (не UPD, която е по избор). TCP, разбира се, привлича природата на сесията. Но UDP е много по-бърз, особено за натоварени услуги. Поради проблеми с DDoS атаки и някои други проблеми със сигурността, сега има модерно движение към преместване на максималния брой услуги към TCP, това е особено вярно за DNS. По-долу обаче разглеждам работата на DNSCrypt само през UDP, тъй като това е традиционната опция за DNS. Препоръчителният номер на DNSCrypt (сървър) порт е 443 (обикновено е отворен в корпоративни мрежи; практиката за използване на 443/udp например е стандартна за редица VPN и други услуги; 443/tcp е TLS/HTTPS, основата на уеб услугите). Yandex обаче използва непривилегирован номер при внедряването на DNSCrypt: 15353, вероятно порадинякои идеи за преодоляване на различни мрежови бариери.
Малко повече за бариерите: няма да има проблеми с блокирането на DNSCrypt трафик, ако доставчикът на канала има такова желание. Както ще стане ясно от описанието по-долу, този протокол не се опитва да скрие самия факт на използването му. В трафика на този протокол са включени стандартни маркери, които ще позволят откриване и филтриране на пакети дори на най-примитивния рутер, като се използва просто двуредово правило. В този случай, например, достъпът за други TCP сесии, работещи на порт 443, ще остане.
Екранната снимка показва пакет със сертификат от DNSCrypt сървъра на Yandex.
Сертификатът е набор от няколко полета: версия на сертификата, стойност на подписа, публичен ключ на сървъра, магически байтове за клиента (те ще служат като идентификатор за клиентски заявки - сървърът ще може да разбере кой ключ да използва, когато отговаря), сериен номер и дата на изтичане.
Като криптографски примитиви DNSCrypt използва конструкции от шифъра Salsa20 (XSalsa20), хеш функцията Poly1305 (за прилагане на удостоверено криптиране) и алгоритъма X25119-hsalsa20 за генериране на споделен сесиен ключ (алгоритъмът използва елиптичната крива Curve25119 и хеш функцията hsalsa20). Тези дизайни са проектирани от Daniel J. Bernstein и отдавна са признати за много солидни. Алгоритъмът за получаване на споделена тайна (сесиен ключ) е математически свързан с алгоритъма на Дифи-Хелман. Отбелязвам, че споделената тайна в този случай може да бъде възстановена след факта, ако съответният таен ключ от двойка сървърни (или клиентски) ключове стане известен, това ще позволи дешифриране на предварително записан трафик, поради което спецификацията препоръчва използванетокъси клавиши.
Шифърът XSalsa20 в удостоверен режим на криптиране изисква nonce с дължина 192 бита (24 байта). Повторното използване на същата комбинация от ключ и nonce не е разрешено. Това се дължи на архитектурата на шифъра XSalsa20 - повторното използване на nonce ще доведе до изтичане: слушателят ще знае XOR стойността от двойка съответни обикновени текстове. Следователно, nonce трябва да бъде нов всеки път, но не непременно случаен. Параметърът nonce в DNSCrypt присъства в две инкарнации: клиент и сървър.
Нека да разгледаме шифрованата клиентска заявка, изпратена от Yandex.Browser.
Първото поле на заявката е магическата стойност на клиента (Client query magic bytes): то използва частта от публичния ключ на сървъра, получена по-рано. Ако е необходимо, тези "магически байтове" могат да служат като подпис, който ви позволява да избирате в заявките за трафик, изпратени до DNSCrypt; Следващото поле е краткосрочен клиентски публичен ключ (Клиентски публичен ключ); Клиентският nonce е 96 бита (12 байта), половината от необходимия nonce за шифъра XSalsa20 (според спецификацията DNSCrypt, подплатен с байтове със стойност 0). Можете да използвате един или друг брояч, "Yandex.Browser" прави точно това: очевидно тук се предава 64-битова стойност на милисекундния времеви печат (време за формиране на заявка), към който се добавят четири байта псевдослучайни стойности. В случай, че това наистина е точно време, предавано в чист вид, отбелязвам, че параметрите на дрейфа на системния часовник са добър знак, който идентифицира конкретно хардуерно устройство - тоест те могат да се използват за деанонимизиране; Последното поле е самата шифрована заявка. Използва се общо криптиранесекретен ключ, който се изчислява от страните въз основа на прехвърлените публични ключове. В случай на клиент, публичният ключ се предава в пакета с DNS заявка (вижте по-горе). Yandex.Browser следва стандартната практика и генерира нова двойка ключове (публичен/секретен) за X25119-hsalsa20 при всяко стартиране на браузъра. За подравняване на данни към границата на 64-байтов блок, както предписва спецификацията, се използва стандартно подпълване (ISO/IEC 7816-4: 0x80 и нулеви байтове, както се изисква).
Криптираният блок от данни най-вероятно е резултат от използването на функцията crypto_box от библиотеката libsodium (или NaCl, която е посочена в спецификацията DNSCrypt; libsodium е разклонение на NaCl). Предположих, че 16-байтовият код за удостоверяване (MAC), който се използва за проверка на целостта на съобщението преди дешифриране, вероятно е в началото на блока. Тъй като обаче не се опитах да дешифрирам данните, определянето на местоположението на кода не е толкова важно. За декриптиране можете да използвате секретния ключ, който се съхранява в паметта, докато браузърът работи, но за да го извлечете, трябва да работите известно време с програмата за отстраняване на грешки и разглобяване.
Криптиран отговор, получен от сървъра:
(Лесно се вижда, че отговорът, представен на екранната снимка, дойде почти пет секунди след запитването защо се е случило това - очевидно тема за отделна бележка.)
Пакетът се отваря чрез магия, в този случай байтове, съдържащи токена за отговор DNSCrypt (отново добър подпис за откриване на трафик). Тези байтове се дефинират от протокола и трябва да присъстват в началото на всеки отговор на сървъра на искане за разрешаване на DNS; Следващото поле е nonce (Response nonce). Полето съдържа стойността nonce, използвана от сървъра при шифроване на даденотоотговор. Полето е изградено от две равни части, по 12 байта всяка: nonce от съответната клиентска заявка и сървърна добавка; Последната част на пакета са криптираните данни за отговор, форматът е подобен на заявката.
Сега нека се върнем към модела на заплахите, използвайки Yandex.Browser като пример. Ако настройките на браузъра позволяват използването на DNSCrypt, например чрез сървъри на Yandex, но достъпът до съответния сървър е блокиран, тогава браузърът (като бета версията) прозрачно, без предупреждение, превключва към използване на системния резолвер. Защо това обезсилва необходимостта от валидиране на DNSCrypt сървърни сертификати? Тъй като активен нападател, който може да фалшифицира пакети на ниво IP, за да деактивира DNSCrypt в браузъра, може просто да блокира достъпа до сървъра, вместо да губи ресурси за създаване на отговори. От това можем да заключим, че моделът на заплахи на Yandex не включва активен спуфинг на пакети по пътя от DNSCrypt сървъра към клиента.
В заключение, няколко думи за връзката на DNSCrypt с DNSSEC. DNSSEC - не крие данните за DNS трафика, но ги защитава от подправяне, независимо от канала за обмен на информация. В случая на DNSSEC няма значение на кой канал са получени данните от DNS, основното е, че ключовете са на мястото си. DNSCrypt - скрива трафика и го защитава в ограничена степен от подправяне по пътя от рекурсивния резолвер (услуга за разрешаване) до клиента. Ако данните са били подправени по пътя към резолвера (или на самия сървър за резолвер) и той не поддържа DNSSEC, тогава клиентът ще получи повредена информация, макар и през защитен DNSCrypt канал. Сървърите, които предоставят DNSCrypt, може също да поддържат DNSSEC.