DANE — новая роль DNS в обеспечении безопасности

В современной Сети основным пользовательским безопасным протоколом работы с сайтами является HTTPS — защищенный протокол на базе криптографии с открытым ключом, практика внедрения которого связана с инфраструктурой удостоверяющих центров. Не вдаваясь в подробности этой практики, отметим лишь пару ключевых для темы статьи фактов. Так как HTTPS — это технология, на клиентской стороне в основном используемая браузерами, то важнейшее значение имеет перечень корневых сертификатов (SSL-сертификатов, «сертификатов безопасности»), встроенных в браузер. Сертификаты, выданные веб-сайтам, для того чтобы пройти валидацию браузером, должны содержать подписи, удостоверенные тем или иным удостоверяющим центром (УЦ). Исходный перечень удостоверяющих центров, поддерживаемых («признаваемых») браузером, определяет производитель браузера, а у пользователя есть возможность внести в этот перечень коррективы. В подавляющем большинстве сценариев использования сертификатов браузеры не различают поддерживаемые УЦ по степени доверия — пользователь вынужден доверять всем УЦ. Несмотря на то, что в Интернете первоначально планировалось создание единого корня для инфраструктуры открытых ключей, коммерциализация услуг по предоставлению сертификатов привела к тому, что сегодня действуют сотни УЦ, каждый из которых является в той или иной степени обособленной коммерческой организацией. При этом отсутствует механизм контроля за тем, какие ресурсы и как удостоверяют эти разношерстные организации, базирующиеся в разных странах.

Результатом стал ряд серьезных инцидентов, связанных с некорректным исполнением удостоверяющими центрами, признаваемыми браузерами, своих технических функций. Наиболее шумной оказалась история с сертификатами, выпущенными в 2010–2011 годах в обход правил (в результате несанкционированного использования информационных систем) удостоверяющим центром DigiNotar для доменов Google (*.google.com и др.) и других доменных имен, соответствующих популярным интернет-сервисам и доменам сайтов спецслужб: www.mossad.gov.il, www.cia.gov, www.facebook.com и др. — всего несколько десятков адресов, для которых было выпущено до нескольких сотен сертификатов (Black Tulip, Report of the investigation into the DigiNotar Certificate Authority breach FoxIT BV, 13 August 2012).

Особенности современной инфраструктуры SSL-сертификатов в Интернете таковы, что пользователь не имеет возможности отличить нелегитимный сертификат, подобный выпущенным DigiNotar, от легитимного. Вполне очевидно, что удостоверяющие центры должны выпускать и подписывать сертификаты для веб-ресурсов только по заказу полномочных представителей компаний (или физических лиц), распоряжающихся этими ресурсами на законных основаниях. Теоретически именно такая разумная практика закреплена и в правилах работы УЦ. Однако отсутствие технических механизмов, позволяющих независимо от инфраструктуры УЦ определить, какой сертификат допустим для заданного имени, привело к тому, что компрометация единичного УЦ стала причиной серьезного глобального инцидента, затронувшего сотни тысяч пользователей.

Серьезности ситуации придает то, что наличие валидного сертификата и соответствующего закрытого ключа, например для домена example.com, позволяет перехватывать и полностью «прослушивать» пользовательский HTTPS-трафик к сервисам, работающим под этим именем, путем организации атаки типа «человек посередине» с подменой сетевого узла. При этом браузер пользователя не будет выдавать никаких предупреждений, полагая, что соединение устанавливается с доверенным сайтом.

Имеется две причины, по которым стало возможным нарушение безопасности. Во-первых, любой УЦ технически может выпустить валидный сертификат для любого домена. Несмотря на то что без веских оснований УЦ так поступать не должен, легитимный владелец ресурса, для сетевого имени которого выпускается сертификат, никак не может повлиять на процесс его выпуска. Более того, владелец ресурса может никогда не узнать, что такой сертификат выпущен и где-то используется для перехвата соединений пользователей с веб-сервером. Во-вторых, пользователи не имеют возможности убедиться, что предъявляемый сертификат выпущен по заказу именно легитимного владельца ресурса, с которым они собираются обмениваться конфиденциальной информацией, а не появился в результате использования злоумышленниками бреши в информационных системах третьего лица — удостоверяющего центра.

Одно из основных предназначений систем безопасности в Интернете — обеспечение возможности определить, кто управляет ресурсом, с которым соединяется пользователь. Важна именно связка «пользователь — владелец ресурса», что отличается от имеющейся «пользователь — удостоверяющий центр».

Необходимо обратить внимание на то, что особенности реализации передачи данных в Сети, а также тот факт, что пользователи в подавляющем большинстве не имеют прямых контактов с владельцами веб-ресурсов вне Интернета, не позволяют построить строгую систему доверия в паре «пользователь — владелец ресурса». Технология DANE (DNS-Based Authentication of Named Entities) — очередной шаг на пути исправления ситуации. Базирующаяся на DNS аутентификация именованных объектов (DANE) — это новая технология, оформившаяся в качестве стандарта лишь в 2012 году. Функция DANE проста — используя криптографические механизмы защищенной версии доменной системы имен (DNSSEC), предоставить владельцам сайтов независимый от сложившейся инфраструктуры SSL/TLS инструмент управления доверием пользователей. Эта задача решается с помощью размещения в DNS дополнительной информации, привязывающей SSL-сертификат сайта к заданному домену.

Пример экрана с сообщением о подозрительном сертификате

Фальшивые сертификаты, выпущенные при помощи DigiNotar, были обнаружены «в дикой природе» Сети только благодаря тому, что браузер Chrome начиная с версии 13 содержит дополнительную проверку сертификатов для сервисов Google. Если при обращении с использованием HTTPS к тому или иному ресурсу Google браузер получает от веб-сервера валидный сертификат, но цепочка валидации не содержит ключа из перечня допустимых для сервисов Google, то пользователю выдается сообщение об ошибке. Один из пользователей, получивший подобное сообщение (cм. рис.), обратился на форум технической поддержки Google, что в итоге и привело к выявлению нелегитимных сертификатов и банкротству УЦ DigiNotar.

Несмотря на то что опыт Chrome оказался удачным, реализованная в браузере технология имеет узкое применение — далеко не каждый сайт может попасть в перечень контролируемых, а кроме того, не все посетители Сети применяют браузер Chrome для просмотра Web. Более гибкое решение, использовавшее DNS и ставшее прообразом DANE, было предложено в 2011 году инженером Google Адамом Ленгли, работавшим в том числе и над браузером Chrome.

Архитектура

Ресурсная запись RFC 6698, регламентирующая DANE, позволяет администраторам доменов определять в DNS криптографические ключи и сопутствующую информацию (эти данные образуют сертификат X.509), используемые TLS-серверами, связанными с этим доменом. Внедрение DANE требует изменений в поддержке TLS на клиентской стороне, но без изменения со стороны сервера. В DNS появляется дополнительная ресурсная запись — TLSA (Transport Layer Security Authentication), служащая для размещения криптографической информации. DANE является логическим слоем над DNSSEC, средствами которого производится удостоверение данных, связанных с записями TLSA.

Информационная структура DANE достаточно проста — для заданного сетевого имени в DNS создается TLSA-запись стандартного формата, данные из нее идентифицируют открытый ключ (либо целиком сертификат), используемый, например, веб-сервером. Основным носителем криптографической информации, используемой для аутентификации серверов при установлении соединения HTTPS, сейчас являются сертификаты группы стандартов X.509, часто называемые SSL-сертификатами. Технически сертификат представляет собой файл с определенной стандартом структурой, задающей поля данных, в которых размещается информация об удостоверяемом ресурсе: адрес, данные администратора/владельца, информация об удостоверяющем центре, сведения об открытом ключе, который использует сервер. DANE спроектирован так, чтобы обеспечить удобную работу именно с сертификатами X.509.

Рассмотрим следующий пример: веб-сервер размещается по адресу dane.nox.su из подписанной DNSSEC зоны nox.su: dane.nox.su IN A 50.16.193.159. Стандартное HTTPS-обращение веб-браузера к серверу под данным именем использует TCP-соединение с номером порта 443, и чтобы для dane.nox.su заработала технология DANE, в корректно подписанной зоне DNS должна находиться корректно подписанная TLSA-запись для имени, которое включает тип соединения, номер порта и имя самого ресурса. Имя для TLSA-записи в нашем случае — _443._tcp.dane.nox.su. Здесь в общепринятой нотации записан стандартный номер порта HTTPS (443) и тип соединения (tcp). Значением для данной записи служит криптографическая информация, используемая соответствующим TLS-сервером (в нашем примере это веб-сервер Apache 2) с установленным модулем mod_ssl и «самоподписанным» сертификатом, в котором совпадают удостоверяющая и удостоверяемая стороны (генерация «самоподписанного» сертификата проводится без участия какого-либо удостоверяющего центра). Соответственно, в зоне DNS TLSA-запись для нашего примера выглядит следующим образом: _443._tcp.dane.nox.su. IN TLSA (3 0 1 12B1BC2AF0D87C6E0E259CE364CE6921B74F0C748328C4A33A11F19467700EB2)

В поле со значением 3 определяется способ использования сертификата TLS-сервера, соответствующего TLSA-записи (0 — TLSA содержит информацию о сертификате УЦ, который обязательно должен быть представлен в цепочке валидации при установлении TLS-соединения; 1 — TLSA содержит информацию о сертификате сервера; 2 — TLSA содержит информацию о корневом сертификате; 3 — TLSA содержит информацию о сертификате сервера, который обязательно должен быть в цепочке конечным сертификатом). Тип 3 позволяет использовать «самоподписанные» сертификаты, придавая им новую степень доверия, которая обусловлена электронными подписями DNSSEC.

Поле со значением 0 содержит селектор, определяющий, какая часть сертификата используется при сопоставлении его содержимого со значением TLSA (0 — сертификат полностью; 1 — открытый ключ сертификата, двоичное представление).

Поле со значением 1 определяет метод сопоставления данных сертификата с данными TLSA (00 — полное точное совпадение; 1 — совпадение значений хеш-функции SHA-256; 2 — совпадение значений хеш-функции SHA-512).

Поле со значением 12B1BC... — это данные TLSA, в нашем примере определяющие значение хеш-функции SHA-256, взятое от полного сертификата.

Перед установлением соединения с сервером dane.nox.su по HTTPS клиент делает запрос в DNS, пытаясь извлечь запись TLSA для _443._tcp.dane.nox.su. В случае успеха и если запись прошла валидацию DNSSEC, клиент сможет проверить соответствие сертификата, возвращаемого сервером при установлении TLS-соединения, информации, полученной из DNS. В случае с dane.nox.su клиент сличает отпечаток «самоподписанного» серверного сертификата с отпечатком, полученным из DNS, значение которого удостоверено DNSSEC. Другими словами, DANE позволяет увязать идентификаторы веб-сервера с идентификаторами DNSSEC в доменной системе имен. Это дает администраторам доменов инструмент управления списком доверенных сертификатов, независимый от инфраструктуры УЦ, а пользователям — независимый от УЦ механизм контроля за тем, каким сертификатам они доверяют. В DNS при этом может размещаться отпечаток сертификата или только открытого ключа. Достоверность данных отпечатка, полученных из DNS, подтверждается подписями DNSSEC.

Как уже отмечалось, DANE не имеет смысла без DNSSEC, и если в DNS отсутствуют механизмы удостоверения данных, то нет никакой возможности проверить, что сведения, содержащиеся в TLSA-записи, не были изменены, однако только для публикации данных TLSA поддержки DNSSEC не требуется. Более того, можно предположить, что размещение подобных записей в DNS без DNSSEC затруднит использование нелегитимных сертификатов. Но необходимо учитывать, что введение описанной схемы без механизмов электронной подписи DNSSEC создало бы новые направления атак, не предоставив дополнительной безопасности. Например, атакующий, который контролирует DNS-резолвер (сетевой сервис, производящий поиск в DNS и сопоставление сетевых имен и адресов), мог бы заблокировать доступ посетителей к легитимному ресурсу по HTTPS, подделав DNS-ответы.

Посмотрим теперь, как использование DANE скажется на проблеме, подобной инциденту с УЦ DigiNotar. Предположим, что пострадал домен example.com и для него, без ведома администратора, выпущены валидные сертификаты. Пусть администратор пользуется услугами УЦ под названием CA-1. Отпечаток сертификата этого УЦ размещен в TLSA-записи для _443._tcp.example.com. Нелегитимный сертификат выпущен УЦ под условным названием CA-2. Пользователь из операционной системы, поддерживающей DNSSEC, при помощи браузера, поддерживающего DANE, обращается к сайту https://examle.com/, однако третья сторона перехватывает его сессию, подставляя сертификат, выпущенный CA-2. Браузер еще до открытия TLS-сессии получил из DNS достоверные данные о сертификате УЦ для example.com и, не обнаружив сертификата допустимого УЦ в цепочке доверия во время установления TLS-сессии, может прервать соединение и выдать предупреждение системы безопасности.

Проблемы и решения

Технология DANE позволяет существенно затруднить, а в ряде случаев сделать невозможным использование сертификатов, выпущенных без ведома администратора доменной зоны, адресующей соответствующий веб-ресурс. Таким образом, DANE — это одно из решений проблемы «неопределенной надежности» сложившейся к сегодняшнему дню иерархии коммерческих УЦ, дополняющее ее независимой административной иерархией, построенной на базе DNS.

Радикальный подход в применении DANE позволяет выстроить в Интернете новую криптографическую инфраструктуру, которая хотя и использует семейство технологий X.509 (TLS/SSL), но не нуждается в коммерческих УЦ, функции которых берут на себя DNS и администраторы доменных зон. Несомненно, здесь есть прямая угроза бизнесу всех удостоверяющих центров, а не только «плохих», особенно в ситуации появления все новых инцидентов, ставящих под сомнение эффективность существующей системы УЦ. В качестве меры примирения DANE и коммерческих УЦ в протокол были введены типы данных, позволяющие разместить в DNS сведения о корневых сертификатах УЦ. Примирение двух технологий позволяет построить кооперативную систему, в которой одна инфраструктура независимо укреплена другой, что повышает уровень безопасности в целом. Тем не менее тот факт, что DANE позволяет удостоверять «самоподписанные» сертификаты, которые до сих пор очень часто используются на сайтах и, естественно, бесплатны, очень привлекает администраторов сайтов.

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

Впрочем, основные претензии к DANE связаны с деятельностью удостоверяющих центров. Действительно, несмотря на все ошибки, взломы и аварии, УЦ хотя бы формально обязаны более или менее строго проверять лиц, которым выдаются сертификаты. В случае с доменными именами регистраторы таких строгих проверок не выполняют, и этого от них не требуется. Формально проверка данных проводится, но обычно это делается постфактум, когда возникли какие-то проблемы. Требование к регистраторам проводить строгую проверку способно подорвать основы регистраторского бизнеса, так как такая проверка существенно увеличит затраты на регистрацию имен, поэтому проверка данных и остается здесь процедурой, скорее, формальной. Так, в подавляющем числе случаев регистрация доменных имен второго и третьего уровня осуществляется в автоматическом режиме на основе простой заявки потенциального администратора. DANE использует систему доменных имен, транслируя, таким образом, принятый в ней слабый уровень проверки на всю иерархию доверия, включая и УЦ.

Возможен следующий сценарий «зловредного» использования DANE. Злоумышленники регистрируют (указав вымышленные данные администратора) фишинговое доменное имя, по написанию сходное, например, с доменом известного банка. DANE позволяет разместить в этой новой доменной зоне данные «самоподписанного» сертификата, тем самым переведя адрес в разряд «безопасных», что дает злоумышленникам приманку, вызывающую дополнительное доверие у пользователей.

Стоит отметить, что на практике среди продуктов УЦ есть сертификаты с минимальной проверкой — так называемые DV-сертификаты (Domain Validated). Для того чтобы пройти проверку при выпуске такого сертификата для домена часто достаточно уметь принимать электронную почту на специальные адреса в нем. Что, естественно, не составляет труда для злоумышленников. Эта ситуация в точности повторяет проблему DANE, что в данном случае не ухудшает практику обеспечения безопасности. Корректное решение состоит в том, что в браузере адреса, которые удостоверяются только при помощи DNS, должны отображаться отлично от адресов, удостоверенных и DANE, и стандартными УЦ. Так, может быть использована разная цветовая индикация в адресной строке — например, удостоверенные только DANE ресурсы отображаются желтым. Логичным будет использовать такой же уровень «цветовой дифференциации» и для DV-сертификатов. При условии добротной реализации браузерами пользовательского интерфейса никаких конфликтов между DANE и сложившейся структурой обеспечения безопасности пользователей не возникнет.

Современное состояние

Рабочее предложение RFC6698, описывающее DANE, получило статус рекомендованного стандарта IETF в августе 2012 года, однако пока поддержка технологии на стороне массового клиента отсутствует. Отчасти это обусловлено слабым проникновением поддержки DNSSEC — отсутствие безопасных зон не позволяет администраторам доменов разместить записи TLSA. Не способствует росту популярности технологии и то, что ни один из современных браузеров не поддерживает DANE штатными средствами.

Прототип технологии DANE был реализован в браузере Chrome в 2012 году, но, за исключением общих идей, не имел общих черт с RFC6698, а в начале 2013 года эта технология была изъята разработчиками из Chrome — ожидалось, что взамен будет внедрена поддержка полноценной DANE, однако до сих пор (апрель 2013 года) этого не произошло.

В сообществе разработчиков Mozilla Firefox вопрос поддержки DANE обсуждался с начала 2012 года, однако каких-то строгих планов по внедрению также пока нет. Имеется плагин для этого браузера, ограниченно поддерживающий DANE, — Extended DNSSEC Validator, однако на данный момент он устарел. Ничего не известно и о планах внедрения технологии в Internet Explorer и Opera, хотя в сообществе данный вопрос обсуждался.

***

Технология DANE отлично иллюстрирует направление движения инженерной мысли в разработке инструментов обеспечения безопасности. Эта изящная, простая технология, построенная на базе фундаментальных элементов современной сети (DNS и HTTP), имеет потенциал для развития, однако для его реализации не хватает поддержки на клиентской стороне. DANE может послужить локомотивом, который потянет за собой массовое внедрение DNSSEC, однако обеим этим технологиям мешает известный парадокс «курицы и яйца»: DANE может потянуть за собой DNSSEC, но развитию DANE мешает отсутствие массовой поддержки DNSSEC; поддержка DANE появилась бы «на клиенте», если бы сайты массово внедрили DANE — но сайты не хотят внедрять DANE, так как нет поддержки «на клиенте».

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

Александр Венедюхин (vened@nic.ru) — руководитель отдела компании RU-Center (Москва).