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

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

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

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

Доменное имя onion, соответствующее зоне .onion, которая используется внутри TOR для адресации скрытых сервисов, включили в реестр специальных доменов IANA. Зона .onion – это особый домен, доступный только при использовании сети анонимизации TOR. Имена .onion являются криптографическими индексами, связанными с ключами, которые аутентифицируют сервис. То есть, адрес .onion также решает задачу обеспечения “подлинности” ресурса (условно, потому что сеть анонимная). Теперь, после того как домен включили в реестр, можно ожидать выпуска хорошо известными удостоверяющими центрами SSL-сертификатов для этой зоны. Через TOR официально работают и некоторые “обычные” популярные сервисы, например, Facebook.

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

Когда в 2010 году технологию DNSSEC внедрили в корневой зоне DNS – не подумали об алгоритме ротации (замены) корневого ключа. В процессе генерирования безопасного файла зоны участвуют два ключа: KSK и ZSK – последний подписывает записи в зоне, а первый, KSK, это и есть корневой ключ, он удостоверяет ZSK. Соответственно, вся валидация делается от корневого KSK (в зонах, которые находятся уровнем ниже, тоже есть свои KSK, но глобальный, корневой, порождает всю цепочку). Всякий валидирующий DNS-резолвер, если он работает с глобальной DNSSEC от IANA, должен содержать копию открытого ключа корневого KSK, это необходимо для проверки подписей из безопасных зон. В общем, корневой KSK – самый важный элемент инфраструктуры DNSSEC, и технология была запущена без алгоритма регулярной замены этого ключа (хотя про интервал замены “раз в пять лет” речь шла). Бывает.

Сейчас истекли пять лет с момента публикации подписанной корневой зоны DNS. KSK пора бы обновить. Это ключ RSA, имеющий длину 2048 бит. Маловероятно, что кто-то успел его факторизовать за пять лет, но есть же и криптографические традиции. Поэтому ICANN ведёт разработку алгоритма ротации корневого KSK, сейчас предварительный документ с рекомендациями проходит стадию публичного обсуждения.

Рекомендовано сохранить используемую криптосистему (RSA) и разрядность ключа (2048 бит), а дата ротации пока никакими рекомендациями не обозначена. Учитывая, что сейчас идёт процесс по “передачи IANA-функции”, всякие решения по точным алгоритмам и датам – могут только затягиваться (в документе по ссылке про изменение политик IANA, конечно, упомянуто).

Вообще, DNSSEC не слишком широко поддерживается – подписанных зон чрезвычайно мало. Не велико и число операторов валидирующих резолверов. Среди них, наверное, самый влиятельный по объёму запросов – Google, который предоставляет сервис Public DNS, поддерживающий DNSSEC. В теории, впрочем, при неудачной замене корневого KSK все валидирующие резолверы через некоторое время сломаются, потому что любая безопасная зона подписана от корня DNS, а подписи в корне перестанут валидироваться. На практике, новый KSK, с проверкой, можно раздать по крупным операторам вручную, а мелкие – починятся после того, как обнаружат сбой. (Несмотря на то, что есть RFC 5011, надеяться на массовую успешную автоматическую замену ключа было бы очень наивно – это уже не в традициях системного администрирования.)

Интересно, что если замена ключа наложится на замену договора с IANA, то процесс затянется ещё на несколько лет. Вообще, в рекомендациях упомянут 2030 год, как год, до которого можно смело использовать 2048-битные ключи RSA, полагая их стойкими (естественно, с оговоркой про “прорывные достижения”). То есть, время для ротации KSK, похоже, ещё есть.

Частота появления новых записок на dxdt.ru снизилась, и вот почему: я за это время написал большой текст про TLS, рассказывающий как этот протокол работает в подробностях. Несмотря на то, что изложение начинается с истории разработки TLS – это технический, ориентированный на специалистов, текст, подразумевающий некоторую подготовку у читателя: местами протокол разобран буквально до байта (в качестве примеров я рассматриваю дампы TLS-сессий). Подробных русскоязычных описаний для TLS очень мало, а протокол этот получает всё большее распространение – неправильное понимание принципов работы TLS ведёт к неприятным ошибкам в реализациях сервисов, которые его используют. Поэтому, думаю, такое описание будет полезно.

Описание я планирую дополнять, потому что, несмотря на объём, охвачены ещё не все аспекты, которые хотелось бы рассмотреть. Сейчас в деталях рассмотрены такие ключевые моменты, как установление соединения (Handshake) и логика построения обмена сообщениями – это основа основ TLS. В ближайших планах: раздел, разбирающий современные шифры (в различных режимах работы), пояснения про использование криптографии на эллиптических кривых. Вероятно, будут исходники на С, поясняющие некоторые моменты реализаций. Конечно, нужен структурный путеводитель по RFC, имеющим отношение к TLS (их великое множество). Для того, чтобы получился полноценный тематический сайт я выделил проекту отдельный адрес: https://tls.dxdt.ru/. (Правда, пока там многое нужно оформить.)

Если есть какие-то поправки, уточнения, пожелания по новым темам (про что написать подробнее) – сообщайте, пожалуйста, либо мне почтой, либо в комментарии к этой записке.

Сам текст:

Ключи, шифры, сообщения: как работает TLS

В управлении современным Интернетом важнейшую роль играет IANA-функция – то есть, полномочия по распределению имён и номеров, по распределению адресных ресурсов. Например, именно IANA управляет корневой зоной DNS (хотя техническую часть – раздачу экземпляра зоны – реализует компания VeriSign). IANA распределяет блоки IP-адресов, или, скажем, утверждает перечни шифронаборов, используемых в TLS. Сейчас данный рычаг управления находится в руках ICANN, которой он был делегирован минторгом США. Примерно два года назад ICANN запустила (ну или возглавила) процесс по переводу IANA-функции под “контроль интернет-сообщества”. Публичное обсуждение началось весной 2014 года. В планах было осуществить такой перевод уже в этом, в 2015, или в следующем году. Понятно, конечно, что даже если осуществить такой перевод вообще реально, то нереально успеть в столь сжатые сроки.

В результате минторг США теперь планирует продлить имеющийся контракт на выполнение IANA-функции с ICANN до сентября 2016 года, а потом – ещё на три года. Это означает, что никакой “передачи управления Интернетом”, как ожидалось, в ближайшие лет пять не случится.

В начале июля с биткоинами приключилась интересная и показательная история, последствия которой до сих пор дают о себе знать. Вот что произошло. В начале года предложили модификацию протокола (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 что-то поправят (вероятно, добавив новых дефектов, так как в сторону упрощения спецификация пока что идёт с большим трудом).