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-трафика конкретного соединения.

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

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

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

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

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

Из имён .ru, корректно подписанных DNSSEC, для которых в DNS указаны записи TLSA (это технология DANE, дополняющая инфраструктуру SSL/TLS) – мне удалось найти только пять, вот они:

dxdt.ru
feuerplatz.ru
lexeyko.ru
megaid.ru
ojab.ru

Это из примерно 4,5 млн делегированных доменов. Мягко говоря, не слишком много.

Небольшая подборка записок по теме TLS/SSL (и близким к ней), появлявшихся на dxdt.ru:

• HTTPS и “открытые веб-страницы”;
• Heartbleed, OpenSSL: работа над ошибками;
• Система прослушивания TLS/SSL от NSA. Часть 1;
• Система прослушивания TLS/SSL от NSA. Часть 2;
• Популярно о перехвате HTTPS;
• Цифровые нотариаты и административное значение TLS/SSL;
• Политика браузеров и история с SSL/TLS;
• Технология DANE: отличия от работы УЦ;
• Новинки безопасности, практикум: настройка DANE и dane.nox.su.

Ещё немного про TLS/SSL: Let’s Encrypt – это инициатива по созданию общедоступного бесплатного удостоверяющего центра (УЦ), а также программных инструментов и сервиса автоматической выдачи сайтам SSL-сертификатов, признаваемых браузерами. Более того, обещают, что сопутствующее ПО будет автоматически настраивать веб-сервер для работы по HTTPS.

Чуть подробнее: предполагается, что утилита Let’s Encrypt, будучи запущенной на сервере, сама сгенерирует ключи, свяжется с удостоверяющим центром, подтвердит управление сайтом (владение доменом), закажет и получит SSL-сертификат и настроит веб-сервер для работы с ним. Всё это с использованием специального протокола, который был разработан ранее. И бесплатно.

Выглядит, конечно, привлекательно. Но вызывает сомнение высокая степень автоматизации: всё ж SSL/TLS иногда требует обдумывания действий, иначе безопасность не повышается, а скорее наоборот. Всякое тиражное решение несёт с собой риск тиражирования не только хороших, правильных практик, но и ошибок, которые сделали разработчики решения. Можно спорить, насколько сильно нужно ошибиться в сервисе, автоматически внедряющем HTTPS на сервере, чтобы в результате ошибки уровень безопасности для этого сервера снизился – предполагается, что до момента запуска Let’s Encrypt сервер вообще использовал открытый протокол HTTP. Всяческие сценарии с захватом управления веб-сервером и автоматическим выпуском сертификата для его домена не очень пугают, так как если кто-то получил управление сервером, то он и так может сделать с ним всё что угодно, в том числе заказать сертификат (тут, впрочем, может потребоваться ещё и контроль электронной почты под доменом). Но, естественно, бесплатность процедуры несколько упрощает атаку.

Нет сомнений, что подобный сервис, к сожалению, окажется удобен для различных фишерских доменов, среди которых есть и простые тайпсквотерские (yanclex.ru), и более хитрые, комбинированные: например, что-нибудь вроде ssl-yandex.ru. Возможность быстро выпустить бесплатный сертификат и поднять HTTPS, вызывающий дополнительное доверие пользователей – она не может быть лишней. Впрочем, сейчас для этих же целей успешно выпускаются платные сертификаты DV (с валидацией по домену), с подставными реквизитами: возможности определить степень легитимности домена УЦ не имеет. Так что радикально Let’s Encrypt тут ситуацию не изменит.

Запуск сервиса обещают летом 2015 года. В числе участников инициативы значатся Mozilla и IdenTrust (это действующий УЦ), то есть можно ожидать появления нового УЦ как минимум в одном распространённом браузере. Как я понимаю, на первых порах Let’s Encrypt планирует вообще использовать для работы корень IdenTrust, с отдельным промежуточным сертификатом (по крайней мере, сейчас у них на сервере HTTPS устроен именно так). В общем, посмотрим, что получится.

Большой проблемой современного состояния SSL/TLS в Интернете является возможная “прозрачная” подмена сертификатов, проводимая при участии удостоверяющих центров. Одним из решений этой проблемы является построение независимой от иерархии удостоверяющих центров публичной системы аудита выданных сертификатов. Соответствующая инициатива называется Certificate Transparency (CT), я писал о ней примерно год назад. Результаты аудита, которые публикуются в специальных логах, могут, в том числе, автоматически проверяться браузерами. Технология активно развивается и уже частично поддерживается браузерами Chrome и Chromium. Конечно, есть проблема с полнотой логов, но важно, что поддержку включили.

Кстати, поговаривают, что в Chrome/Chromium будут требовать поддержки CT для EV-сертификатов (сертификатов с “дополнительной валидацией”) с февраля 2015 года. То есть, уже совсем скоро.

Посмотреть, как работает эта новая технология, можно, например, здесь: https://embed.ct.digicert.com/.

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

Откуда взялась уязвимость? В TLS добавили расширение Heartbeat (RFC 6520), довольно экзотическое, и уж точно не критическое для большинства современных сценариев использования TLS в Интернете. По сложившейся традиции, реализацию этого расширения быстренько загнали в OpenSSL. А в результате внедрения этой мало кем востребованной штуки – миллионы сервисов, сами того не желая, получили по огромной дыре. Они, выходит, использовали данное расширение TLS только для того, чтобы желающие могли получать несанкционированный доступ к оперативной памяти. Такая вот безопасность.

Что же было на другой чаше весов? То есть, ради чего добавляли новый код? Что могли бы получить такого полезного от данного расширения TLS все те миллионы сайтов, если бы реализация была выполнена без ошибки? Да в общем – ничего особенного: гипотетическую оптимизацию вычислительных затрат на управление TLS-сессиями. Очевидно, есть некие “структурные проблемы” в процессах создания протоколов, раз так получается.

Хотя, конечно, TLS не сломан, всё идёт своим чередом. Есть шансы, что новая версия TLS будет проще, а пачку расширений отрежут. Посмотрим.

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

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

Кстати, это очередной хороший пример, объясняющий, почему может быть полезно хранить полный дамп шифрованного трафика. В штатных логах данная утечка никак не отражается, то есть, обнаружить в логах, что утекли ключи – не выйдет (только предположить, что могли утечь). А вот в дампе трафика ключи вполне себе будут заметны, и утечку можно детектировать с высокой точностью.

Пара полезных ссылок:

Diff исправления уязвимости (добавлена проверка границы области памяти, в общем-то, достаточно очевидная для опытного аудитора кода; но такой аудитор должен был ещё посмотреть в код, да).

Онлайн-инструмент для проверки уязвимости конкретного веб-сервера (проверил – похоже, работает корректно).

Сейчас нередко приходится слышать, что тотальный переход сайтов на HTTPS помешает проведению “мягких блокировок” избранных сайтов провайдерами. Потому что в HTTPS, для инспектора трафика, не видны полные URL. Впрочем, тут можно напомнить про SNI – в рамках этой технологии, практически все современные браузеры, охватывающие, наверное, не менее 90% пользователей, передают имя хоста, с которым устанавливают TLS-соединение (HTTPS), в открытом виде:

То есть, хоть URL-ов и не видно, но адрес сайта, с которым пытается соединиться пользователь, системам инспекции трафика (DPI) доступен: блокируй – не хочу.

Вообще, полезно иметь в виду, что ни TLS, ни, тем более, HTTPS, не разрабатывались для преодоления систем фильтрации и блокирования доступа, так что как-то радикально повлиять на ситуацию они не могут. Хотя, конечно, проведение “тонкого блокирования” затрудняют. Но проблема не в этом. Да и “тонкое блокирование” – похоже, мало кому нужно.

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

В продолжение записки про ошибку “goto fail” в операционных системах Apple. Это очень показательный случай, очередной. Ошибка, заключающаяся в одной элементарной строке кода, приводит к тому, что “защищённое” соединение можно перехватывать без проблем. И практических методов защиты от использования этой ошибки – нет.

Сравнение отпечатков сертификатов никак не помогает, потому что сертификат используется легитимный, полученный с сервера – ошибка гарантирует, что не проверяется соответствие подписей. Подмена IP-адреса сервера может происходить с помощью DNS, это традиционный способ. Тут, в принципе, некоторую защиту обеспечивает DNSSEC, но только если атакуемый домен подписан (а это вряд ли). Более того, во многих сетевых конфигурациях (скажем, в чужой WiFi-сети) подмену сервера можно провести, сохранив его IP-адрес, то есть, DNSSEC уже никак не поможет. DANE – только добавит пользователю уверенности, что всё хорошо, так как отпечатки сертификатов из DNS и с подставного сервера – совпадут.

Вот.

Так работает современная массовая криптография. Один оператор goto – и больше нет защиты. Совсем.

(Продолжаем криптографическую серию заметок.) Оказывается, в Firefox версии 26 включили поддержку OCSP staplig. Что это такое? OCSP (Online Certificate Status Protocol) – это протокол, позволяющий клиенту (браузеру) в режиме онлайн проверить не был ли представленный сервером SSL-сертификат отозван. Напомню, что отзыв сертификата – это специальная процедура, позволяющая исключить из списка доверенных сертификат, срок действия которого ещё не истёк. Это требуется, например, в том случае, если скомпрометирован закрытый ключ, соответствующий сертификату.

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

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

Я некоторое время назад наладил демонстрационный сервер под доменом 1d.pw, там поддерживается и OCSP stapling – только сертификат там не EV, а простой. Посмотреть на работу OCSP stapling можно при помощи OpenSSL, вот так:

$ openssl s_client -connect 1d.pw:443 -tlsextdebug -status

В выдаче отыскиваем строки, следующие за “OCSP response”:

OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)