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

В начале июля с биткоинами приключилась интересная и показательная история, последствия которой до сих пор дают о себе знать. Вот что произошло. В начале года предложили модификацию протокола (BIP66), которая изменяет требования к формату записи значения электронной подписи, используемой при проведении транзакций. Новые блоки, поддерживающие изменённый формат, должны иметь версию 3. Так как это существенное изменение, оно вводится согласованно, а именно: если из предыдущих 1000 блоков 950 имеют версию 3, то новые блоки, имеющие старую версию 2, считаются невалидными (не соответствующими протоколу). Или, другими словами, в блокчейне (цепочке Blockchain) должен появиться отрезок, на 95% состоящий из блоков новой версии, после этого блоки, имеющие старую версию, не принимаются, соответственно, если большинство узлов-майнеров следуют протоколу, цепочка должна мягко перейти на новую версию.

Но на практике случился занятный сбой. Некоторые майнеры, достаточно мощные пулы, приступают к вычислению нового блока без проверки параметров предыдущего блока, к которому они планируют пристроить новый. Эти майнеры генерируют блоки версии 3, но сами не проверяют, что предыдущий блок также является блоком версии 3. Собственно, они вообще ничего не проверяют, так как в погоне за скоростью начинают вычислять свой блок, как только увидят значение хеша для нового блока, только что включённого в блокчейн. При этом значение хеша они получают через тот или иной API, предоставляемый специальными серверами крупных майнинг-пулов, а не используют штатную P2P-сеть Биткоин. Естественно, значение хеша в принципе не позволяет понять, что за версия у предыдущего блока. (Такой метод майнинга, – SPV-майнинг, – кроме прочего, подразумевает, что в блок скорее всего не будет включено пользовательских транзакций, кроме транзакции, зачисляющей новые биткоины на адрес майнера.)

После того, как цепочка блоков достигла требуемого интервала в 95% блоков новой версии, небольшой майнинг-пул опубликовал новый блок, который только что вычислил. Этот майнер использовал необновлённое программное обеспечение, поэтому он добавил в блокчейн блок версии 2 (этот блок можно увидеть на сайте blockchain.info). Всё бы ничего, но торопливые майнеры, без проверки, быстро пристроили к этому блоку ещё пять, создав ветвление блокчейна: так как породивший ветку блок второй версии не должен был быть включен в блокчейн (из-за нарушения протокола), другие майнеры продолжали строить блокчейн от предыдущего блока. Это ветвление приключилось 4 июля 2015 года. Позже, невалидные блоки были вытеснены основной веткой, которая обогнала сбойный участок по сложности (протокол биткоин предписывает добавлять новые блоки в ветку с максимальной суммарной сложностью). Однако транзакции, попавшие в сбойную ветку оказались отменены, а ресурсы, потраченные на вычисление блоков – потеряны.

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

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

Вот так человеческий фактор и неверное управление доверием, – когда новый протокол принимают, но не проверяют присланные блоки на соответствие, – едва не привели к весьма большим неприятностям для биткоинов. Можно, кстати, услышать, что 4-5 июля эта криптовалюта избежала катастрофы, но это, всё ж, преувеличение.

В доменной зоне .RU среди самых популярных названий УЦ, выдавшего серверный SSL-сертификат, неожиданно лидирует COMODO ECC Domain Validation Secure Server CA 2. Лидерство – по числу уникальных серверных сертификатов, которых, под доменами .RU, обнаруживается более 7 тыс.

Этим именем (COMODO ECC…) обозначается промежуточный SSL-сертификат, ключи от которого используются для подписывания клиентских, серверных сертификатов. Главная особенность сертификата в том, что он использует механизм электронной подписи ECDSA – на эллиптических кривых (то есть, используется не самая распространённая криптосистема RSA, а другая, как считается, более прогрессивная в плане длины ключей и используемых примитивов). Сертификат с криптографией на эллиптических кривых позволяет использовать эту криптографию и на сервере. Если у вас сертификат с подписью RSA, то сервер также должен использовать только RSA для генерации подписи, иначе браузеры не смогут корректно установить соединение.

Занятно, что виновником прогресса эллиптической криптографии в Рунете оказался сервис CloudFlare – именно он поддерживает большинство из тех сайтов, серверы которых отдают “эллиптические” сертификаты. Соответствующий промежуточный сертификат УЦ в CloudFlare используют для автоматической генерации на лету нужных валидных (признаваемых браузерами) сертификатов для клиентов. Так как CloudFlare на одних и тех же узлах обслуживает большое количество разных сайтов, необходимо использовать технологию SNI, чтобы определить сайт, к которому происходит обращение. А чтобы браузер не выдавал предупреждение – в составе сертификатов присутствуют все имена, которые поддерживает данный сервер: они перечислены в поле расширений SAN (Subject Alternative Name).

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

Сейчас начинают появляться сообщения в СМИ, что концепция с общим журналом действий (главной книгой), аналогичным Blockchain от криптовалюты Биткоин, может быть взята на вооружение “прогрессивными банками”. Это забавно, потому что сам протокол и инфраструктура биткоинов – изначально направлены на то, чтобы банк, как третье лицо, не фигурировал в платёжной системе. Совсем не фигурировал. То есть, банку там просто нет места, хотя, теоретически, он может выступать держателем основных вычислительных мощностей в системе криптовалюты, но такая конфигурация начисто вымывает весь смысл затеи. Про то, как работают биткоины, я подробно писал раньше.

Занятно, что в Microsoft уже некоторое время используют неподходящий SSL-сертификат для windows.microsoft.com: предъявляемый сервером сертификат выпущен для *.windows.microsoft.com, а это имя, естественно, не подходит, так как работает только для четвёртого уровня. Такая вот неразбериха.

В свете недавно выявленной уязвимости TLS – Logjam возник интерес к отличиям различных версий и реализаций алгоритма Диффи-Хеллмана. Вообще, современное состояние дел с криптографией в Интернете таково, что вместо небольшого набора простых и понятных протоколов, используется огромная куча спецификаций, в которых, по историческим причинам, наворочено много разных тонкостей. Одна из таких тонкостей – отличие шифронаборов, содержащих в своём обозначении DH, от шифронаборов с DHE (добавлен суффикс E).

DH – обозначает Диффи-Хеллмана. E – Ephemeral (почему-то сейчас в переводе используют “эфемерный”, хотя лучше подошло бы “краткосрочный” или “единовременный”). Обычно пишут, что вариант DH – не обладает прогрессивной секретностью (то есть, записанный ранее трафик можно раскрыть через какое-то время, если удалось получить секретный ключ сервера), а DHE – обладает. В чём же различия?

Вспомним, что алгоритм Диффи-Хеллмана использует следующие общие параметры: P – модуль (большое простое число, задающее группу, в которой производятся вычисления – (mod P), дальше это обозначение опускаю); G – “генератор” (число, элемент выбранной группы). Это публичные параметры. Условный “открытый ключ” сервера образуется при помощи вычисления A = G^a, где a – секретная часть ключа (экспонента). Клиент выбирает своё значение b, вычисляет B = G^b и передаёт на сервер. Для получения общего секрета сервер и клиент вычисляют, соответственно, s = B^a = (G^b)^a = G^(ba) и s = A^b = (G^a)^b = G^(ab). Обратите внимание на параметры со стороны сервера: P,G,A.

В случае реализации DH предполагается, что параметры сервера (P,G,A) – заранее подписаны неким внешним ключом, что позволяет клиенту проверить их подлинность. Это означает, что параметры фиксированы от сессии к сессии, а сервер может использовать только одну экспоненту (a), которая соответствует G^a = A. Самое важное, что фиксируется именно экспонента a – сервер должен её сохранять в долговременной памяти, так как она связана с открытой частью ключа A. Есть старые рекомендации, предписывающие включать параметры DH в состав сертификата. Впрочем, на практике такие вещи не встречаются. Понятно, что если секретные ключи сервера, а именно – значение a, оказались раскрыты, то они позволят вычислить сеансовые ключи (s) для всех записанных сессий, так как теперь аналитику известна величина a и он может определить s = B^a = G^(ab) (значение B – сохранено в записи трафика, так как его в открытом виде передаёт клиент). Очевидно, что точно так же можно раскрыть трафик, если аналитику известен секретный параметр на стороне клиента (b) – например, этот параметр утёк из браузера.

Итак, основная особенность: в случае DH – заранее предполагается, что секретный параметр алгоритма Диффи-Хеллмана сохранён на диске и может быть доступен третьим лицам. Дело в том, что само по себе использование одинакового параметра для разных сессий никак не гарантирует его раскрытия.

В случае DHE – как минимум a и G^a = A – генерируются сервером заново для каждой сессии, и, как считается, значения не сохраняются на долгое время. А для того, чтобы клиент мог провести аутентификацию параметров, они подписываются ключом сервера (тот же ключ используется в SSL-сертификате). Это нормальный современный вариант использования алгоритма Диффи-Хеллмана в TLS.

Но здесь есть хитрость, про которую почему-то редко упоминают. Хитрость в том, что математически обе схемы (DH и DHE) не отличаются. Различается лишь реализация управления секретом на сервере – в случае DH он обязательно сохраняется, так как строго определён для всех сессий, а в случае с DHE – сохраняться секрет не должен. Но если вдруг секретный сессионный параметр DHE как-то записывается, например, в дампе внутреннего трафика, или в “снапшоте” памяти сервера, или – благодаря особой утечке, связанной с ошибкой в программном коде, то никакой “прогрессивной секретности” уже не получится: DHE становится равен DH, а записанный ранее трафик можно расшифровать.

В продолжение истории об уязвимости в протоколе TLS, получившей название Logjam. Использование уязвимости базируется на нестойких параметрах алгоритма Диффи-Хеллмана – малого модуля, длиной в 512 бит (так называемый “экспортный вариант” параметров алгоритма). Для того, чтобы успешно применить эту уязвимость в реальности, требуется совпадение нескольких факторов:

1) атакующий должен иметь возможность активно перехватывать TLS-соединение. То есть, между клиентом и сервером должен находиться активный перехватывающий узел, не просто умеющий делать DPI, но работающий с весьма сложной логикой: нужно находить в TCP-трафике сообщения TLS, декодировать их, “завешивать” сессии, подменять информацию в пакетах;

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

3) атакуемый TLS-сервер должен поддерживать заведомо устаревшие “экспортные параметры” алгоритма Диффи-Хеллмана.

Да, “сильные игроки” могут себе позволить первый и второй пункт. Но так как эти пункты затратные, наверняка там очередь заявок стоит, то использовать их имеет смысл только против “важных целей”. И тут возникает некоторое несоответствие: почему интересующий специальное агентство сервер должен находиться под столь неумелым администрированием, что на нём используют “экспортные параметры”? Мало-мальски ценные сервисы, которые думают о безопасности, – они давным давно отказались от “экспортных параметров”. Про то, что это проблемная конфигурация, известно много лет. Поэтому добротно настроенные системы, которыми должны бы пользоваться “важные цели”, применяют современные параметры. Соответственно – против них указанная уязвимость заведомо не сработает (ведь даже сервисы Google попадают здесь в категорию безопасных).

Что, конечно, не отменяет пользы от привлечения внимания к дефекту протокола. Есть шанс, что в TLS 1.3 что-то поправят (вероятно, добавив новых дефектов, так как в сторону упрощения спецификация пока что идёт с большим трудом).

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

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

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.

Сейчас из некоторых российских сетей недоступны 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 пока что не имеет должного распространения.