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

Update (30/10/16): новые сертификаты, выпущенные WoSign, больше не являются доверенными в распространённых браузерах.
Update (12/11/15): к сожалению, выпуск бесплатных сертификатов на три года прекратился; теперь УЦ WoSign предлагает только одногодичный сертификат для пары имён, одно из которых – ваш домен с префиксом www.

Китайский удостоверяющий центр WoSign.com выдаёт бесплатные SSL-сертификаты со сроком действия три года (три года – это ключевое отличие от других бесплатных сертификатов). Работает всё достаточно просто и удобно, я потестировал: заявка на сертификат заполняется на одной странице, занимает это несколько минут, если у вас уже готов файл с CSR (запросом на выпуск сертификата). Есть опция, позволяющая использовать запрос CSR, генерируемый на стороне УЦ. Но это несколько странно, так как в таком случае секретный ключ также генерируется на стороне УЦ, что не является лучшей практикой (хотя, на практическую безопасность влияет не сильно). Поэтому лучше использовать собственные ключи и собственный файл CSR.

Подтверждение прав управления доменом, указанным в заявке, проводится стандартно для DV-сертификатов (DV – Domain Validated): на один из адресов электронной почты направляется письмо, содержащее код подтверждения. Это, кстати, важный момент: уровень защищённости процедуры выпуска DV-сертификатов не превышает уровень защищённости вашей почтовой системы и инструментов управления доменом. То есть, если кто-то может получать письма на адрес вида postmaster@domain.tld (или admin@ и др.), то этот кто-то может заказать и получить вполне валидный SSL-сертификат для данного домена (и, обычно, поддоменов). Тем не менее, схема работает: получаем код в почтовом сообщении, подтверждаем на странице заказа сертификата.

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

В рамках проверки сервиса я успешно выпустил сертификат для dxdt.ru, где в качестве дополнительных имён используются www.dxdt.ru и tls.dxdt.ru. WoSign позволяет указать до 100 имён в сертификате, что весьма удобно, если у вас несколько поддоменов используются в рамках проекта (веб-почта, форум и т.п.). Полученный от WoSign сертификат я уже установил на отдельном хосте: https://tls.dxdt.ru/ – кому интересно, можете посмотреть, как оно работает. На этом сервере несколько виртуальных хостов, поэтому требуется поддержка SNI (есть во всех современных браузерах). Корень, от которого выпускают сертификаты в WoSign (CN = Certification Authority of WoSign, O = WoSign CA Limited), включен и в Mozilla, и в Chrome.

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

Очередной раз отмечу, что технически бесплатные сертификаты ничем не отличаются от платных. Более того, за исключением несущественных деталей (содержания некоторых полей), сами сертификаты различной степени проверки (DV, OV, EV и, в частности, Wildcard) также технически эквивалентны: на уровень защиты канала связи браузер-сервер – тип проверки не влияет. То, какой именно УЦ выпустил ваш сертификат, никак не влияет и на возможности по перехвату HTTPS-трафика конкретного соединения.

Хэш-функция SHA-1 уже несколько лет считается недостаточно стойкой для использования в подписях SSL-сертификатов. Сейчас идёт процесс вытеснения этой функции из действующих сертификатов, но пока что таких сертификатов много, они встречаются сплошь и рядом. Использование SHA-1 приводит к “неожиданным” эффектам в браузерах. Посмотрим на один из примеров – сайт nic.ru.

На сервере, где расположен nic.ru, установлен валидный сертификат с расширенной проверкой (EV). Однако если зайти на сайт при помощи браузера Chrome (42.0.2311.90 – актуальная на момент написания заметки версия), работающего в среде операционной системы Windows (версии 8.1, например), то в адресной строке браузера появляется предупреждение о том, что сайт использует устаревшие технологии безопасности. Выглядит это так:

Естественно, ожидается, что корректно установленный EV-сертификат приведёт к другому эффекту, отобразив “доверенную” адресную строку. Так происходит в браузере Internet Explorer 10, на той же тестовой машине:

А если воспользоваться браузером Mozilla Firefox, то эффект тоже положительный:

Впрочем, положительный эффект в Firefox имеет под собой другую почву, нежели случай IE. Что происходит, почему браузеры ведут себя именно так?

Посмотрим на набор сертификатов, возвращаемых сервером. Здесь есть три сертификата: серверный и два промежуточных; вот их свойства, указанные в полях Subject (s, предмет сертификации) и Issuer (i, удостоверяющая сторона):

0.
s:O=JSC ‘RU-CENTER’/OU=Project Department/CN=www.nic.ru
i:O=GeoTrust Inc./CN=GeoTrust EV SSL CA – G4

1.
s:O=GeoTrust Inc./CN=GeoTrust EV SSL CA – G4
i:O=GeoTrust Inc./CN=GeoTrust Primary Certification Authority

2.
s:O=GeoTrust Inc./CN=GeoTrust Primary Certification Authority
i:O=Equifax/OU=Equifax Secure Certificate Authority

(Имя nic.ru без www. указано в расширении SAN сертификата, так что адреса на скриншотах – корректны.)

Проблемным является сертификат под номером 2 (выпущенный для GeoTrust Primary Certification Authority), так как он использует SHA-1 в составе алгоритма генерации подписи. Согласно политике Google Chrome, если в цепочку сертификатов (исключая корень) входит хотя бы один, подписанный с использованием SHA-1, то в адресной строке выводится предупреждение. Посмотрим на цепочку:

Всё сходится – промежуточный сертификат с SHA-1 входит в цепочку сразу после корня. (Обратите, кстати, внимание на то, что корень обозначен как GeoTrust, хотя сам корневой сертификат содержит название Equifax, в чём можно убедиться, если посмотреть внутрь его полей. Это следы маркетинга: бизнес по продаже цифровых сертификатов Equifax был продан компании, оказывающей эти услуги под брендом GeoTrust.) IE использует тот же набор корней, однако политика этого браузера позволяет даже EV-сертификатам быть подписанным по цепочке, включающей SHA-1, поэтому здесь всё хорошо.

А вот Firefox использует собственный набор корней, поэтому цепочка валидации тут иная:

Firefox содержит доверенный корень, обозначенный как GeoTrust Primary Certification Authority, от которого подписан промежуточный сертификат GeoTrust EV SSL CA – G4. То есть, те же сертификаты уже выстраиваются в цепочку, которая не содержит SHA-1, поэтому данная ситуация не может вызвать предупреждения, даже если бы такое предупреждение поддерживалось Firefox. Аналогично устроен и Google Chrome под Linux – там тоже встроен корень, позволяющий избежать использования промежуточного сертификата с SHA-1.

Выше я упомянул о том, что присутствие SHA-1 не учитывается для корневых сертификатов (встроенных в браузеры). Почему? Причина в том, что корневые сертификаты самоподписанные (по определению), а браузер доверяет не подписи, а открытому ключу, связанному с корневым сертификатом, и имени удостоверяющего центра, которое указано в сертификате. Раз подпись не играет ключевой роли, то и использованием SHA-1 в корневом сертификате можно пренебречь: оно никак не влияет на уровень доверия.

Что нужно делать веб-сайтам? Нужно перевыпускать сертификат в цепочке, которая не использует SHA-1.

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

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

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

Сейчас из некоторых российских сетей недоступны NS-ы GoDaddy, например, вот эти: ns20.domaincontrol.com, ns19.domaincontrol.com. На данные серверы имён делегировано много доменов, соответственно, как только завершится время кэширования, сайты под такими доменами станут недоступны для пользователей российских провайдеров. Из США и Европы – пока что всё работает, серверы “Премиум-DNS” GoDaddy – тоже доступны, пока что. Но, возможно, это авария, ну или ошибка в настройках маршрутизации (как обычно бывает).

Update (17/04/15): исправили; проблема наблюдалась для нескольких групп серверов, и не только для России.

US-CERT распространил новое предупреждение об угрозе: “трансфер зоны DNS может раскрыть информацию о домене“. Это довольно странно, потому что известно очень много лет, соответственно – какая новая угроза? (В предупреждении, впрочем, сказано, что причина в большом распространении серверов, разрешающих трансфер зроны для всех желающих.)

Запросы AXFR (Asynchronous Transfer Full Range) – трансфер зоны – позволяют получить с сервера имён полный список записей в зоне DNS, то есть, фактически, увидеть все настройки адресации домена. Эти запросы используются для передачи сведений между разными авторитативными серверами, поддерживающими зону, а также в других случаях. Разумное толкование подсказывает, что все данные, публикуемые в глобальной DNS, должны являться публичными, по определению. Те не менее, доступ на трансфер зоны обычно ограничивают некоторыми доверенными серверами, чтобы не всякий мог скачать всю зону одним запросом, а только те узлы, которым это нужно. Так делается много лет.

Вообще, споры о том, нужно ли считать угрозой возможность получения полного (или близкого к полному) списка записей в той или иной доменной зоне – идут уже сильно дольше десяти лет. Например, этот момент повлиял на технологию DNSSEC. Для того, чтобы подтвердить, что записи для некоторого имени не существует, в DNSSEC нужно передавать в ответ на запрос указание на “ближайшую” существующую запись (на имя записи). Изначально разработчики DNSSEC пошли по “открытому пути” и предложили решение с записями NSEC, которые, в ответ на запрос о несуществующем имени, просто включают одно из имён в зоне, в открытом виде. Естественно, это позволяет быстро перебрать все записи и получить полный список имён, реконструировав зону. Защитники “безопасности через сокрытие” выставили кучу возражений, в результате появилось расширение NSEC3, где ответы содержат не сами имена, а значения хеш-функций, что делает перебор вычислительно трудным.

Так вот теперь, похоже, нужно ждать свежего “открытия” “угрозы” раскрытия списка имён доменной зоны через NSEC в технологии DNSSEC. Хотя, DNSSEC пока что не имеет должного распространения.

Существуют EV-сертификаты для TLS. Это сертификаты с расширенной проверкой организации, для домена которой выпускается сертификат. Технически, они такие же, как и обычные, но красят адресную строку в некоторых браузерах в зелёный цвет. Теперь для EV-сертификатов нужна поддержка Certificate Transparency (согласно рекомендациям разработчиков браузеров; сейчас требование актуально только для линейки Google Chrome). Посмотрим, как это выглядит на практике, для пользователя браузера Chrome (англоязычный интерфейс). Для примера я возьму сайт интернет-банка “Альфа-банка”. Сведения о статусе аудита Certificate Transparency (CT) отображаются в выпадающем окошке, по клику на название организации в адресной строке браузера:

Наличие строки Transparency information говорит о том, что в сертификате содержатся записи из логов CT. По клику открывается окно с дополнительной информацией:

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

Сведения о включении сертифката в лог CT содержатся в самом сертификате, для этого в расширения X.509 внесено специальное поле:

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

Сейчас корни китайского УЦ CNNIC не поддерживается браузерами (Chrome и Firefox) в полном объёме, это результат истории с выпуском “перехватывающих” промежуточных сертификатов. Google ставит в качестве условия возврата доверия CNNIC-у – полную поддержку Certificate Transparency (CT). Интересно, что если CNNIC такую поддержку реализует, то это будет первый УЦ, который реализовал CT в полном масштабе даже не потому, что есть RFC, а лишь под давлением разработчиков браузеров.

Подробное описание уязвимости CVE-2015-1130 в Apple OS X и истории её обнаружения, с примерами кода. Уязвимость позволяет произвольному пользователю получить файл, исполняемый на локальной машине с правами root. Для эскалации привилегий используется системный API, в котором содержится ошибка. Пишут, что уязвимость существовала как минимум с 2011 года.

Технология HSTS (HTTP Strict Transport Security) позволяет принудительно переводить браузер в режим HTTPS для некоторых URL, это требуется для того, чтобы предотвратить активные атаки, основанные на замене протокола. Однако на базе HSTS придумали делать “суперкуки” – то есть, идентифицировать браузер, даже если он работает в “анонимном” режиме, не отправляет куки-файлы. Технология довольно занимательная: используется несколько адресов сайтов, с разным состоянием HSTS, это состояние (HTTP/HTTPS) соответствует одному биту идентификатора; javascript-ом состояния битов считываются с набора сайтов и собираются в число, идентифицирующее браузер. Конечно, требуется несколько десятков адресов (например, 32), но это не проблема.

У iPhone есть функция, которая стирает пользовательские данные с устройства, если PIN-код на экране блокировки введён неверно 10 раз. Казалось бы, подобрать даже четырёхзначный код нереально – шанс угадать слишком мал. Тем не менее, пишут про электронное устройство, которое PIN-код успешно подбирает. Хитрость в том, что устройство, обнаружив ошибочный ввод по показаниям дисплея, моментально отрубает питание телефона (для реализации этого требуются вскрыть корпус и подключить прерыватель). Из-за алгоритмической ошибки в процедуре обработки ввода PIN-кода, телефон не успевает записать новое значение счётчика попыток в память, поэтому после перезагрузки можно попробовать ещё раз (пишут, что примерно 111 часов нужно для проверки всего множества кодов).

Насколько можно понять, речь об уязвимости CVE-2014-4451, которая датирована 18 ноября 2014 года и должна быть уже закрыта. Очевидно, что ошибка разработчиков состоит в последовательности шагов алгоритма: нужно сперва увеличивать значение счётчика попыток в энергонезависимой памяти, а только потом выводить результат проверки на экран (не наоборот). Очень показательный пример того, что в реализации функций обеспечения безопасности подобная “мелочь” может начисто удалить все защитные свойства.

Китайский удостоверяющий центр CNNIC, признаваемый всеми основными браузерами, поучаствовал своими ключами в выпуске промежуточного сертификата, который использовался в прозрачно перехватывающем трафик SSL-прокси. Об этом, конечно, стало быстро известно в Google (потому что браузер Chrome устроен достаточно добротно). Объяснения от CNNIC сводятся к тому, что, дескать, это всё была тестовая среда, а сертификаты утекли наружу случайно. Итог пока такой: корень CNNIC таки изымают из продуктов Google:

“As a result of a joint investigation of the events surrounding this incident by Google and CNNIC, we have decided that the CNNIC Root and EV CAs will no longer be recognized in Google products.” (В результате совместного расследования событий, связанных с данным инцидентом, мы приняли решение что CNNIC Root и EV УЦ больше не признаются продуктами Google.)

Это весьма резкое решение, но, собственно, такого варианта следовало ожидать. Mozilla пока думает, но в том же самом направлении. А для повторного включения корней CNNIC в браузеры планируют потребовать от УЦ поддержки Certificate Transparency.

В CNNNIC уже ответили, в том ключе, что шаг Google – неприемлем, требуют задуматься о правах пользователей.

Ссылка по теме: перехват HTTPS.

Update, 04/04/15: Mozilla подключилась – сертификаты, впущенные от корней CNNIC после 1 апреля 2015, не признаются. Таким образом, CNNIC, как коммерческий УЦ, теряет всякий смысл. Интересно, как прореагируют в Китае?