dxdt.blog: занимательный интернет-журнал

Как известно, перехват HTTPS проще реализовать при участии удостоверяющего центра, который, технически, может выпустить особый сертификат, позволяющий перехватывающему узлу выдать себя за легитимный сервер, с которым планировал соединиться пользователь. Эта особенность протокола ставит удостоверяющие центры в положение, когда их (вполне обосновано) постоянно подозревают в выпуске “перехватывающих сертификатов”. Или, как минимум, в содействии такому выпуску. После недавних “разоблачений АНБ” эта, чисто административная ситуация, сильно обострилась. Проблем добавляет и тот факт, что стандартные средства TLS/SSL, изначально разработанные для защиты коммерческих транзакций, выполняемых через Интернет, сейчас используются жителями разных стран с целью защиты личных сообщений и прочих важных данных.

Тут возможно техническое решение, которое ввело бы некий дополнительный распределённый нотариат, поддерживаемый сообществом и, поэтому, независимый как от удостоверяющих центров, так и от разработчиков браузеров. Я писал про инициативу Certificate Transparency, она как раз является одним из таких нотариатов. Так вот, интересно, что удостоверяющим центрам появление такого сервиса должно бы быть полезным. Этот сервис, если он будет развёрнут повсеместно, лишает выпуск “перехватывающих сертификатов” всякого смысла: встретив подобный сертификат, браузер всё равно будет выдавать предупреждение системы безопасности. И это должно снять подозрения с удостоверяющих центров.

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

Впрочем, нужно подождать, посмотреть, что выпустят производители браузеров.

Продолжение рассказа о гипотетическом устройстве системы перехвата защищённого интернет-трафика. В первой части рассматривается расшифровка TLS-трафика. Но чтобы было что расшифровывать, трафик нужно сперва перехватить.

Итак, получение трафика реализуется с помощью его перенаправления или копирования в сети NSA. Перенаправление реализует транзитный узел, который нужно правильно подобрать. Пользовательский интерфейс наверняка устроен следующим образом: оператор вводит требуемый IP-адрес, обозначающий либо пользователя, либо сервер; система находит в базе данных, хранящей сведения о топологии сети, подходящие точки присутствия NSA, через которые может проходить трафик для заданного IP, проверяет, что этот трафик там есть, обнаружив трафик – ставит его на прослушивание, включает перенаправление. Нужно различать два режима работы с трафиком: активный и пассивный. В пассивном случае трафик лишь копируется в анализирующий сегмент. В активном – перенаправляется, то есть, между двумя точками, устанавливающими соединение, появляется дополнительный узел. Кстати, активный режим, работающий на уровне IP, сейчас штатно используется интернет-провайдерами для фильтрации доступа к интернет-ресурсам. Так что это вполне стандартный инструмент.

Тут есть ряд трудностей. Маршруты, по которым ходят пакеты в Интернете, могут меняться, соответственно, нужно найти действующий маршрут, а в дальнейшем – следить за его возможными изменениями. Кроме того, подключение пользователя с “внутренним” IP-адресом, из адресного пространства локальной сети, может находиться за неким транслятором адресов, внешний адрес которого соответствует и другим пользователям. Очевидно, задача упрощается, если в качестве исходных данных используется адрес не только пользователя, но и сервера, с которым он работает. Проще перехватывать трафик заданного сервера, но и поиск путей перехвата только “по пользователю” тоже реализуем, если у вас в распоряжении суперкомпьютер, анализирующий таблицу BGP, и вы видите определяющий маршруты технический трафик на портах крупнейших мировых транзитных узлов.

Перехват интернет-трафика обычно представляют на уровне IP или близких к этому протоколу уровнях. Однако в реальности существуют более “глубокие” уровни, позволяющие коммутировать каналы и пересылать пакеты данных в самые разные центры обработки. То есть, сведения из таблиц BGP требуется для поиска точек подключения клиентов и серверов, для построения списков транзитных узлов. Но сам перехват может быть реализован на уровне других протоколов, относительно которых реализация IP-транспорта является виртуальной надстройкой.

Итак, после того, как подходящие узлы перехвата определены, вычисляется, возможна ли работа в активном режиме. Активный режим необходим для осуществления атаки типа “человек посередине”. Действительно, транзитный узел (например, маршрутизатор), может сделать с проходящим через него трафиком всё что угодно. В том числе, направить трафик для определённых адресов по специальному маршруту, завернув его в сеть NSA в прозрачном режиме. При идеальной реализации, единственное, что может выдать систему анализа, это возросшая задержка при установлении соединения. Однако активный режим требует возможности управления, условно говоря, коммутацией: нужно добавлять дополнительный узел в цепочку. Пассивный – может быть реализован значительно проще, без доступа к начинке коммуникационного оборудования: достаточно установить на физический канал оптический сплиттер (ну или подключиться к проводам, если они вдруг используются).

Хорошие кандидаты на роль узла перехвата: пограничные маршрутизаторы провайдеров доступа; точки подключения дата-центров; узлы опорных сетей крупнейших операторов связи; усилители оптических сигналов и так далее, это далеко не полный список. При наличии бекодров в прошивках домашних роутеров, последние также становятся хорошим инструментом перехвата пользовательского трафика. Система “тотального” перехвата должна предоставлять единый “уровень абстракции”, позволяющий получить нужный трафик вне зависимости от того, на каком узле и каким способом он физически перехватывается. Это вполне реализуемо, если у вас есть коллектив разработчиков, достаточно вычислительных мощностей и пропускной способности собственных каналов связи. Понятно, что у NSA тут проблем нет.

Кстати, по этой же теме: “Вывод информации, снятой с подводных кабелей“.

Интересно представить, как может работать гипотетическая система “тотального” прослушивания NSA защищённого интернет-трафика. Защищённый интернет-трафик, в подавляющем большинстве случаев, использует TLS/SSL, с теми или иными SSL-сертификатами. Самый известный пример такого использования – защищённая версия HTTP, HTTPS, его и возьмём в качестве примера. Другим источником сведений о гипотетической системе послужат скриншоты неких интерфейсов доступа и другие фрагменты презентаций, которые были опубликованы в СМИ. (Напомню, что я уже писал о перехвате HTTPS ранее.)

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

Начнём со второй задачи, с расшифровки или предотвращения шифрования данных, предположив, что трафик уже перехвачен.

В принципе, протоколы TLS (HTTPS) проектировались из соображений, что канал передачи данных между пользователем и сервером может прослушиваться и перехватываться в активном режиме. Поэтому TLS, в теории, позволяет защитить данные от прослушивания и обнаружить активное вмешательство в канал. Что с этим можно сделать? Я уже не раз рассказывал о том, что есть возможность подмены серверного сертификата с дальнейшим перехватом соединения. Эта опция доступна, если с вами сотрудничает удостоверяющий центр, которому доверяет программное обеспечение пользователя. Но есть ещё один вариант: можно получить серверный закрытый ключ. В таком случае для перехвата можно использовать действующий сертификат сервера, он всем доступен, его достаточно просто скопировать. При наличии серверного ключа можно и проводить атаку типа “человек посередине”, и расшифровывать данные в пассивном режиме (если сервер настроен подходящим образом). Атака “человек посередине” предотвращает шифрование данных в точке перехвата.

Как получить серверный ключ? Если NSA внедряет закладки в программное и аппаратное обеспечение, то, вероятно, есть возможность вычислить секретный ключ за разумное время. Например, для самой популярной криптосистемы RSA достаточно знать разложение на простые множители модуля, используемого в данном секретном ключе. (Модуль – это, грубо говоря, число, задающее множество, в котором проводятся операции для даннной пары закрытый/открытый ключ.) Это не единственный способ, есть множество других. Закладка NSA с указанными свойствами приводит к уменьшению количества возможных ключей. В качестве наиболее вероятного рычага воздействия закладки принято называть генератор (псевдо)случайных чисел. Действительно, как бы хорошо не была реализована сама криптосистема, если практическое число возможных ключей, порождаемых генератором “неслучайных” чисел, не велико, то и от самой системы толка нет.

Тривиальный пример. Предположим, в NSA, воздействуя на производителей криптомодулей, на разработчиков программного обеспечения, добились того, что количество простых чисел, используемых в качестве одного из сомножителей в ключах RSA, которые генерируются “сертифицированными средствами”, не превышает 10^12 (триллион). Второе число может быть истино случайным, ведь тут важно не переборщить: чрезмерно малое разнообразие ключей будет быстро обнаружено наблюдателями (см. историю с ошибкой в Debian OpenSSL, которая, кстати, теперь уже и не кажется просто ошибкой). Зная структуру множества этих выбранных простых чисел, можно быстро вычислить секретный ключ простым перебором. Чуть более технично: пусть модуль ключа RSA представляет собой произведение двух простых чисел; если наш суперкомпьютер выполняет миллион пробных делений в секунду, то, исходя из 10^12 вариантов известных множителей, мы получим разложение для модуля не более чем через 278 часов; это означает, что факторизация будет обычно занимать чуть более недели. Заметьте, что серверные ключи традиционно существуют в неизменном виде годами.

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

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

Вычисленный ключ попадает в базу данных и становится доступен пользователям системы прослушивания HTTPS. Трафик можно начинать записывать сразу, не дожидаясь готовности ключа. Например, если взглянуть на те же веб-сервера Mail.ru, то они, как и подавляющее большинство других сервисов Интернета, не поддерживают прогрессивной секретности (forward secrecy) для HTTPS, это означает, что ранее записанный трафик можно расшифровать позднее, когда станет известен серверный ключ. (Подчеркну: я не вижу тут какой-то ошибки со стороны Mail.ru – они просто следуют сложившейся практике.)

Продолжение про перехват HTTPS – в следующей части, рассказывающей о перехвате трафика.

В связи с ростом интереса к перехвату “всего и вся” структурами NSA, часто стали упоминать HTTPS. Думаю, полезным будет некоторый небольшой популярный обзор HTTPS, как раз с точки зрения его прослушивания. Ниже, кроме HTTPS, фигурируют такие связанные понятия, как TLS/SSL, SSL-сертификат.

Итак, ряд базовых моментов.

1. HTTPS – это HTTP, работающий по “защищённому каналу”. Технологии, служащие для создания такого канала для HTTPS, называются TLS (SSL). TLS используется не только HTTPS. Обычно предполагается, что трафик, передаваемый по упомянутому каналу, может быть доступен третьей стороне, которая, однако, не должна иметь возможность раскрыть сами передаваемые данные (“защита от прослушивания”, реализуется шифрованием; заметьте, впрочем, что HTTPS можно устроить без шифрования, но это будет являться ошибкой).

2. SSL-сертификаты служат для проверки подлинности узлов, устанавливающих TLS-соединение. Такая проверка – не связана с шифрованием. SSL-сертификаты не являются секретными. В тайне требуется держать только секретный ключ, соответствующий открытому, который опубликован в составе SSL-сертификата. Для организации сеанса HTTPS используются серверные SSL-сертификаты и, очень редко, также клиентские SSL-сертификаты (последние позволяют реализовать взаимную аутентификацию).

3. SSL-сертификаты не связаны с собственно шифрованием данных HTTPS, но они позволяют создать зашифрованный канал. Однако такой канал может быть создан и без использования сертификата. Функция SSL-сертификата, применительно к HTTPS, состоит лишь в удостоверении связки некоторого имени ресурса и некоторого открытого ключа. В качестве имени ресурса обычно выступает доменное имя (пример: dxdt.ru). То есть, при помощи серверного SSL-сертификата, клиент (обычно – браузер) может удостовериться, что соединяется именно с обладателем секретного ключа из пары, открытая часть которой указана в сертификате. Этот процесс часто называют аутентификацией сервера. Если специально задаться целью, то несложно реализовать TLS-соединение с проверкой SSL-сертификата, но вообще без шифрования.

4. Зашифрованный канал связи между клиентом и сервером использует сеансовый ключ, этот ключ – секретный и симметричный, то есть, его знает и клиент, и сервер. Генерация общего сеансового ключа, в большинстве случаев, происходит с использованием открытого ключа, указанного в серверном SSL-сертификате. В зависимости от используемого алгоритма, серверный ключ либо служит для шифрования данных, необходимых для создания сеансового ключа, либо для проверки подписи на этих данных.

5. TLS (и, следовательно, HTTPS) использует для реализации защищённого канала самые разные наборы криптографических алгоритмов (шифров, подписей, кодов аутентификации, дайджестов и так далее). Если какая-либо часть этого набора выбрана неверно, то соединение будет уязвимым, вне зависимости от того, какие ключи и SSL-сертификаты использовались. Если набор выбран верно, но генерируется нестойкий сеансовый ключ, то, опять же, соединение будет уязвимым, вне зависимости от того, какие шифры и SSL-сертификаты использовались.

6. Для большого класса добротных, стойких криптосистем, широко используемых сейчас в TLS на практике, возможно восстановление сеансового ключа из записанного трафика, при условии, что атакующая сторона имеет в своём распоряжении секретный серверный ключ (это ключ из той пары, открытая часть которой указывается в сертификате сервера). Это означает, что однажды получив секретный ключ сервера (не сеансовый!), кто-то может расшифровать накопленные ранее записи HTTPS-сеансов между клиентом и сервером. Упомянутый ключ может быть раскрыт разными способами: например, его можно скопировать с сервера, если есть доступ, или он может просто оказаться нестойким (такое случается не так редко, как можно подумать).

7. Если генерация секретного сеансового ключа проводится по алгоритму Диффи-Хеллмана, то наличие серверного секретного ключа никак не помогает восстановить его из записанного трафика. Однако на практике далеко не все TLS-серверы используют соответствующие алгоритмы.

8. Если атакующая сторона получила соответствующий сеансовый ключ, то она может раскрыть HTTPS-трафик. Секретный серверный ключ или SSL-сертификат для этого не требуются.

9. Возможность выпустить SSL-сертификат для атакуемого домена никак не помогает расшифровать HTTPS-трафик, идущий в этот домен, даже если трафик записывается. Это так потому, что SSL-сертификат не содержит секретного серверного ключа (и, очевидно, сеансовых ключей). Более того, процедура выпуска сертификата не требует передачи секретного ключа в удостоверяющий центр (передаётся только открытый ключ), поэтому у удостоверяющего центра секретного ключа нет.

10. Тем не менее, валидный SSL-сертификат, выпущенный для атакуемого домена, позволяет провести незаметную для пользователя атаку типа “человек посередине”. Для этого требуется, чтобы между атакуемым пользователем и сервером существовал управляемый атакующим узел, активно перехватывающий трафик. Этот узел выдаёт себя пользователю за легитимный сервер, предъявляя тот самый валидный сертификат. Пассивное прослушивание канала не позволяет раскрыть HTTPS-трафик подобным образом – наличие сертификата или секретных ключей УЦ никак тут не помогает.

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

12. Атаку “человек посередине” невозможно проводить в отношении тех серверов (и сервисов), трафик в направлении которых не проходит через перехватывающий узел. То есть, атака, по определению, активная и индивидуальная.

13. “Человек посередине” не работает для HTTPS при наличии некоторых дополнительных мер: например, установление TLS-соединения требует взаимной аутентификации, и перехватывающему узлу недоступен клиентский секретный ключ (либо ключи УЦ, удостоверяющего клиентский ключ); или – пользовательский браузер ведёт реестр отпечатков открытых ключей сервера, которым он доверяет; или – пользователь применяет дополнительные источники сведений о разрешённых ключах и сертификатах, которые недоступны для подмены на перехватывающем узле (таким источником может служить DNS, либо другая база данных).

14. Все (хорошо – подавляющее большинство) сколь-нибудь массовые сервисы используют так называемый SSL termination: то есть, пользовательский HTTPS-трафик в зашифрованном виде доходит только до пограничного прокси, где благополучно транслируется в HTTP, который дальше ходит по внутренним (в логическом, а не техническом смысле) сетям сервиса в открытом виде. Это стандартная практика, так как тотальный HTTPS, с ростом числа клиентов, быстро превращается в неподъёмную, плохо масштабируемую технологию. Если система инспекции трафика находится внутри сетей сервиса, за таким пограничным SSL-прокси, то никакой HTTPS ей не мешает. Внутренний трафик распределённых сервисов с легкостью ходит между узлами и дата-центрами по арендованным у крупных операторов каналам связи в открытом виде, такой трафик может прослушиваться, хотя для пользователя он выглядит как HTTPS-соединение.

15. Если на компьютере пользователя присутствует троянская программа, имеющая доступ к браузеру, то HTTPS также оказывается бесполезным, так как данные могут копироваться вовне до того, как попадут в зашифрованный канал.

Вот.

Кстати, касательно перехвата и расшифровки, при содействии сервис-провайдера, трафика HTTPS, идущего, скажем, между пользователем и веб-почтой. Ключи от SSL-сертификата для этого не являются необходимыми. SSL-сертификат обеспечивает не шифрование, а аутентификацию (идентификацию, если трактовать иначе); основное предназначение сертификата – привязать имя “субъекта” (например, доменное имя) к некоему публичному ключу. Да, после того, как ключ, связанный с сертификатом, признан достоверным, с его помощью организуется шифрование потока данных. Но для этого шифрования используется другой ключ – сеансовый. Специальный сертификат нужен для организации атаки типа “человек посередине”, а не для расшифровки записанного трафика.

Для того чтобы расшифровать ранее записанный трафик, требуется сеансовый ключ. Этот ключ – симметричный, его экземпляр есть на сервере (и на клиенте). Предположим, что трафик записывается где-то на пути, в точке перехвата, находящейся между клиентом и сервером, например, это зеркальный канал на опорной сети. Сервер запоминает сеансовые ключи (это, кстати, требуется для управления TLS-сессиями), а позже передаёт их копии стороне, записавшей трафик. Теперь трафик можно расшифровать и разобрать постфактум. И вот сеансовый ключ, как раз, строго необходим для расшифровки сообщения. При условии, что HTTPS реализован в современном варианте, запись трафика и, позже, получение только секретного ключа, соответствующего SSL-сертификату, не позволяет расшифровать трафик, так как для генерации сеансового ключа используется протокол Диффи-Хэллмана.

Небольшое дополнение к прошлой заметке по теме, рассказывающей о контроле доверия в DANE. Напомню, речь идёт о том, что DANE, в случае применения с самоподписанным сертификатом, основывается только на административной иерархии DNS. А там, во многих случаях, не тщательно проверяются данные администраторов доменов. (Тут нужно заметить, что есть и виды SSL-сертификатов, которые также выдаются без особых проверок – достаточно управлять почтой на домене, для которого вы заказали сертификат.)

Так вот, есть ещё одно важное отличие между DANE+TLS (SSL) и чисто TLS (SSL). В случае с DANE, для того чтобы воспользоваться предоставляемыми возможностями и мимикрировать под “безопасный сайт” злоумышленнику нужно зарегистрировать другой домен. (Взлом цепочки управления DNS тут не рассматриваем.) Да, домен может быть визуально похож на адрес атакуемого сайта, как в хрестоматийном примере yandex.ru и yanclex.ru, но это другой домен. В случае же с имеющейся инфраструктурой удостоверяющих центров, выдающих SSL-сертификаты, злоумышленник может получить сертификат для того же самого домена. Что, кстати, не исключает тем более беспроблемного получения сертификата для условного yanclex-а. То есть, благодаря особенностям DNS, отличие DANE принципиальное – нельзя зарегистрировать и разместить в глобальной DNS второй домен, точно совпадающий с атакуемым. А вот выпустить без ведома администратора домена SSL-сертификат для него – можно. Естественно, с существенными оговорками, но, опять же, без взлома цепочки доверия. Свежее доказательство – история с TURKTRUST.

Это преимущество DANE.

История с чередой “поломок” удостоверяющих центров, выдающих SSL-сертификаты, наводит на довольно логичный вывод: коммерческую систему “управления доверием” могут очень сильно перекроить. Потому что момент подходящий.

Вообще, иерархия удостоверяющих центров в реализации браузерных криптографических схем с SSL вводится при помощи одного вроде бы простого утверждения: обязательно требуется механизм, позволяющий проводить идентификацию предъявителей сертификатов с помощью “третьей стороны”. Напомню простой пример: кто-то предъявляет браузеру SSL-сертификат, выпущенный для домена test.ru – откуда браузер знает, что этот кто-то действительно имеет отношение к test.ru? Выпустить самоподписанный сертификат для test.ru может кто угодно.

Страшилка: этот “кто угодно” может вмешаться в канал связи и выдать себя за владельца test.ru. Неожиданным образом, этот момент лежит в основе продаж SSL-сертификатов. Предлагается поступать так: пользователь выбирает некую доверенную организацию, которая проверяет, что предъявитель сертификата действительно представляет test.ru; теперь пользователь принимает только те сертификаты для test.ru, которые подписаны доверенной организацией. Вроде бы, все довольны.

Но в реальности – проблемы. Например, оказалось, что эти самые “доверенные организации” могут подписать что угодно. Либо в результате взлома, это как раз основа нынешней шумихи, либо вполне себе осознанно, скажем, действуя в рамках сотрудничества с производителями систем мониторинга трафика. Самое занятное, что ни пользователь браузера, ни тот, кто приобретает SSL-сертификат, не могут повлиять на ситуацию и как-то предотвратить подобное использование имеющейся инфраструктуры: в браузеры встроены десятки “корней” удостоверяющих центров (УЦ), каждый из них технически может подписать любую ерунду. Выходит, что для пользователей и потребителей SSL-сертификатов от коммерческих УЦ заявленный механизм идентификации не факт, что работает. (Да, понятно, что можно возразить: нет, работает! Но плана для проверки всё равно не реализовано.)

Кстати, а нужен ли вообще этот механизм удостоверения “третьей стороной”? Существует другой подход, предусматривающий сохранение некоторого уникального “отпечатка” (это может быть открытый ключ, например) при первом “контакте” с другой стороной, участвующей в обмене данными. В дальнейшем проверяется, не изменился ли отпечаток. Понятно, что если в канал связи кто-то вмешался и выдаёт себя за другого, то такая подмена будет обнаружена (если, конечно, этот “другой” не принял чужую личину с самого начала). Например, так работает SSH. Тут есть свои проблемы, их много. Но есть и крайне привлекательный момент: в схеме участвуют только те, кто действительно обменивается данными и им не нужно звать “третью сторону”, в том числе, в финансовом плане.

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

И вот тут появляется DNS и DNSSEC. В DNS единый корень. Как раз доменное имя (читай – инфраструктура DNS) позволяет типичному пользователю установить “первый контакт” с неизвестным ему ранее сайтом. DNSSEC, понятно, также содержит единый корень и подписать “что попало” – не выйдет, так как доменные имена должны быть уникальны. С чисто технической точки зрения с помощью DNSSEC можно удостоверить не только адресную информацию, но и дополнительные сведения, например, указать, какие именно сертификаты – или, что конкретнее, криптографические ключи, – может использовать сайт под данным доменом. Заметьте, существующая иерархия УЦ здесь уже не нужна!

Но главное, что криптографическая часть от DNSSEC уже неплохо популяризована, корневые ключи сгенерированы, а у руля уже стоит бренд VeriSign, который хорошо узнаваем и в отношении SSL-сертификатов.

Так что шумиха раскручена не просто так. Наверняка готовятся очень интересные перемены.

Дополнение: да, понятно, что при условии изменения порядка и появления у DNSSEC новой роли, корректирующей судьбу SSL, к бизнесу по “управлению доверием” прямо подключаются регистраторы доменов.