Контроль доверия в DANE

5. December 2012, 18:34 Безопасность, Интернет

Существует технология DANE, позволяющая использовать DNSSEC для контроля достоверности SSL-сертификатов. Пока что, технология эта далека от практического внедрения, хоть и выглядит очень привлекательно. Существенный вклад в формирование этой привлекательности вносит тот факт, что DANE позволяет придать столь популярным “самоподписанным сертификатам” новый статус, привязав их к цепочке доверия DNS. Конечно, только если в домене уже работает DNSSEC.

У DANE, впрочем, есть некоторые особенности, – скорее, негативные, – которые связаны с тем, что для обеспечения управления доверием используется DNS. Причём, фактически, важную роль играет административная структура этой системы, а не чисто техническая.

Предположим, что кто-то желает перехватить соединение с веб-сайтом, работающим по HTTPS, не вызвав каких-то предупреждений в браузере и подозрений у пользователя. Предположим, что DANE выступает в качестве замены инфраструктуры SSL. Тогда, для незаметного перехвата, достаточно получить управление серверами имён, поддерживающими домен, в котором находится атакуемый сайт. Серверы можно взломать. Или просто изменить на свои. Существенный момент: потребуется перехватить и управление записями DNSSEC в зоне уровнем выше, либо заполучить секретный ключ, с помощью которого подписывается зона. При правильном сопровождении домена – сделать это непросто. Однако нельзя исключать, во-первых, взлома панели управления регистратора, а, во-вторых, того, что на каком-то этапе какой-то провайдер DNS может “посотрудничать” с “заинтересованными лицами”.

Дальнейшие шаги понятны: генерируется “самоподписанный” сертификат для атакуемого домена (сайта), вносятся записи DANE в доменную зону, и всё – готово: HTTPS-соединение качественно перехвачено.

Теперь сравним это “безобразие” с ситуацией, когда используется “штатный” SSL-сертификат, выданный в рамках современной общепринятой инфраструктуры, а DANE – не существует. Злоумышленник, получивший тем или иным способом управление зоной DNS, в которой находится адрес атакуемого сайта, без труда сможет перенаправить посетителей на свой сервер. Однако, так как поддержки DANE нет, для того, чтобы представить этим посетителям видимость легитимного HTTPS-соединения, придется как-то выпустить валидный SSL-сертификат для атакуемого домена. И тут требуется взаимодействие с третьей стороной, с удостоверяющим центром, который нужно либо обмануть, либо взломать. Справедливости ради отмечу: и то, и другое – неоднократно проделывалось специалистами на практике. Но факт, что DANE тут может сыграть на руку атакующей стороне, остаётся фактом.

Этот, только что описанный, момент, а также довольно интересное наблюдение, говорящие нам о том, что если удостоверяющие центры во многих случаях обязаны тщательно проверять клиентов, которым выдают сертификаты, а регистраторы доменов тщательную проверку могут не проводить (не проводят, естественно; иначе – рынок рухнет), являются основными аргументами против внедрения DANE. Но есть надежда, что технологию таки введут в обиход, несмотря на эти потенциальные проблемы. Проблемы можно задавить тщательной реализацией DANE в браузерах.

(Напомню, что в спецификации DANE учтены случаи использования SSL-сертификатов, выданных удостоверяющими центрами, которые могут входить в существующую “браузерную” инфраструктуру; а могут и не входить, да.)

Адрес записки: https://dxdt.ru/2012/12/05/5343/

Похожие записки:



Далее - мнения и дискуссии

(Сообщения ниже добавляются читателями сайта, через форму, расположенную в конце страницы.)

Комментарии читателей блога: 8

  • 1. 5th December 2012, 20:16 // Читатель jno написал:

    Пора сползать на IPv6.
    Раздавать “пожизненные” адреса и забыть про DNS как таковой: кому надо – запомнит, кто захочет – в /etc/hosts запишет.
    Ну, да некоторые фичи отсохнут (вроде load balancing на round robin DNS), так и фиг с ними – железки дешевеют.

  • 2. 5th December 2012, 20:18 // Читатель jno написал:

    Просто впечатление создаётся, что все крайние навороты скорее снижают *среднюю* безопасность, чем наоборот.

  • 3. 5th December 2012, 20:41 // Александр Венедюхин:

    Несомненно. Так и есть. Технологии должны бы быть простыми и компактным. На практике так не выходит, к сожалению.

  • 4. 6th December 2012, 14:37 // Читатель jno написал:

    На практике…

    на практике – по-разному выходит.
    смотря, чья практика, наверное.
    от того, что творится в DNS за версту разит “маркетингом” в худшем смысле слова.

    я, конечно, из темы уже выпал, но ошушенья в организме от таких вот отголосков – не самые приятные.

  • 5. 7th December 2012, 18:18 // Читатель sarin написал:

    складывается впечатление, что для создания безопасного Интернета следует переходить к технологиям, аналогичным применяемым в I2P. предпосылки очевидны: доверия нет никому, кроме самых проверенных. сила Интернета в его распределённости. в то время как DNS и тем более концепция удостоверяющих центров приводит к некоторой (довольно сильной) неоднородности сети. это приводит к усложнению масштабируемости и проблемам вроде бутылочного горлышка. но только в свете безопасности они выглядят несколько иначе: при наличии ограниченного и известного списка удостоверяющих центров (или DNS-серверов в случае DANE) условный противник может получить некий контроль над аутентификацией, что в итоге делает возможной атаку типа “человек посередине”. выход мне видится в максимальном распределении аутентификации. ведь если список доверенных узлов для подтверждения подлинности источника не известен, или не является конечным то условный противник столкнётся с определёнными проблемами.

    каждый участник сети должен стать одновременно и удостоверяющим центром, и прокси до других удостоверяющих центров. при установке защищённого соединения на стадии аутентификации следует получать подтверждающую информацию (отпечатки ключей) у некоторого (три?) количества других узлов которые по отношению к данному являются доверенными. они же, в свою очередь, при отсутствии отпечатков запрашиваемых ключей перезапросят их у тех кому уже доверяют они.

    разумеется такой подход имеет огромные технологические трудности обусловленные трудностями построения надёжных P2P вообще, возведёнными в степень тех трудностей которые всегда присущи вопросам безопасности. но превратив Интернет в однородную мешанину узлов с равномерным распределением функций и сильно запутав маршруты пакетов и цепочки доверия можно вывести его на новый уровень открытости и доверия, сделать его более демократичным за счёт исключения влияния центральных элементов коими являются удостоверяющие центры.

  • 6. 7th December 2012, 19:09 // Александр Венедюхин:

    Верно. Следующая DNS может быть распределённой, в смысле представления адресной информации, конечно, сервера там и сейчас “распределены”. Но проблемы с внедрением поверх этой среды “центральной” иерархии – опять возникнут.

  • 7. 10th December 2012, 14:38 // Читатель jno написал:

    sarin, кто за всё платить будет?
    “где деньги, Зин?!”(С)В.С.Высоцкий

  • 8. 11th December 2012, 17:46 // Читатель Саша Сергеев написал:

    Вообще DANE предлагает сделать возможным отказ от CA но к нему не призывает. Намного разумнее использовать TLSA записи для ограничения возможности хакеров купить сертификат у продавца не особо проверяющего покупателя или легко ломаемого. TLSA будет указывать что подобный сертификат должен быть признан фальсифицированным и данные на такой сервер отправлять не надо.

    Комментатору:
    Считать DNSSEC “Центральной Иерархией” глупо. Множество организаций договаривается и учавствует в подписании корневой зоны (root). Записи (DS) вносимые в неё от TLD регулируются самими TLD, решающими всё за себя. Записи от всех доменов – выданы самими доменами и всё это распределено. Человеческий мозг пытается свести это всё к тому что “есть структура”, но на самом деле своим собственным доменом управляете вы сами.

    В любом случае, если вам не нравится DNSSEC и DANE – придумайте свои решения проблем для которых они созданы и опишите их в IETF-draft: http://datatracker.ietf.org/submit/