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

Вот, ICANN выяснила, что с массовым вводом новых доменов верхнего уровня не всё так гладко, как говорится, “с точки зрения безопасности”. Грозят отодвинуть сроки внедрения.

(Вообще, про .corp и прочие .lan – с самого начала было понятно: глобальное делегирование таких имён дело скользкое, и не только из-за проблем с SSL-сертификатами.)

Сейчас проходит очередная массовая атака на сайты, работающие под CMS WordPress. В этот раз она сводится к POST-запросам по адресу /wp-login.php. Видимо, это следы попытки подбора паролей. Отличие этой атаки в том, что запросы приходят с очень большого числа IP-адресов, что несколько затрудняет блокирование. Похоже, атака касается только сайтов в домене .ru (но тут нет уверенности). Поток запросов велик, кто-то активировал ботнет: например, на одном из сайтов я сейчас вижу около 20 POST-запросов в секунду.

Кстати, прошлая массовая атака была устроена несколько хитрее.

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

Вот.

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

Бороться с таким положением дел можно, кроме прочего, с помощью построения дополнительной открытой системы аудита сертификатов, назависимой от УЦ и доступной для использования каждому, кто заинтересован в дополнительной проверке полученных с сервера сертификатов. При поддержке Google развивается как раз такая система: Certificate Transparency (CT). Основные задачи, которые могут быть решены при помощи CT: затруднить выпуск SSL-сертификатов для домена, невидимый администратору этого домена; позволить администратору домена узнать, какие сертификаты для его домена были выпущены; оградить клиентское программное обеспечение от доверенного использования неправомерно выпущенных сертификатов. Решается всё при помощи ведения лога, содержащего описания сертификатов. Подробности есть на сайте.

На сайте журнала “Доменные имена” появился PDF весеннего выпуска. Почитайте. Темой номера стал Интернет после апокалипсиса. А статья “Главной темы” (с.34) рассказывает о грядущей сегментации Сети и о возможном установлении в ней “государственных границ”:

Введение границ в Сети не отменяет обмена трафиком между разными национальными сегментами. Очевидно, такой обмен может осуществляться через несколько пограничных узлов, подразумевая возможную «инспекцию» трафика. Ведь именно такова практика, выработанная на офлайновых государственных границах. Для организации производительных «пропускных пунктов» потребуются вычислительные ресурсы, но они сейчас доступны.

«Пропускные пункты» позволят осуществлять и популярное блокирование интернет-ресурсов на основании решения уполномоченных органов. Фильтрация при этом может осуществляться в двух направлениях, исключая проникновение разного рода вредоносного трафика из виртуального зарубежья в национальные информационные системы. В конце концов именно так корпоративные сети борются с вирусной активностью и DDoS-атаками.

Mozilla опубликовала новую политику управления корневыми сертификатами, входящими в дистрибутив браузера. В новой версии включили пункт, ставший реакцией на скандалы с удостоверяющими центрами (пункт 3 в разделе Enforcement Policy). Речь там о потенциальном исключении корневого сертификата УЦ из браузерного списка доверенных, если станет известно, что удостоверяющий центр выпустил сертификат для того или иного домена не убедившись, что получатель сертификата действительно этим доменом управляет.

Опубликованный текст политики, в итоге, содержит ссылку на требования CA/Browser Forum (CAB-форум – это сообщество, в рамках которого производители браузеров взаимодействуют с УЦ), а не прямое упоминание процедур проверки контроля над доменом. Но, в принципе, требования CAB-форума как раз и состоят в необходимости проведения такой проверки. Так что, по крайней мере формально, удостоверяющий центр, содействующий выпуску SSL-сертификатов для “чужих доменов”, рискует вылететь из списка доверенных. (Напомню, что упомянутые сертификаты служат для перехвата HTTPS-трафика, адресованного любому домену, в прозрачном для пользователя режиме.)

В качестве попутного результата исследования связки TLS и DNSSEC сделал под адресом 1d.pw (краткий домен, кстати) веб-сервер, поддерживающий TLS/SSL (с сертификатом, выпущенным “хорошо известным УЦ”, а также с современными серверными штуками вроде TLS 1.2, OCSP stapling и Strict Transport Security). Домен, естественно, подписан DNSSEC и содержит запись DANE, указывающую на используемый сертификат. В отличие от dane.nox.su – здесь SSL-сертификат не самоподписанный.

Между тем, The Old Reader, который я упоминал в заметке про замену Google Reader, – похоже, всё ж завершает своё существование: проект закрывают сами разработчики, у которых нет больше сил на его сопровождение и развитие. Цитата:

Last week difficulty level was changed to “hell” in every possible aspect we could imagine, we have been sleep deprived for 10 days and this impacts us way too much.

(На прошлой неделе уровень сложности поменялся на “Ад” во всех возможных аспектах, которые мы могли вообразить, мы не спали десять дней, это слишком сильно на нас повлияло.)

Такое вот продолжение проекта получилось.

Кстати, для Рунета мне известны три источника статистики использования на сайтах систем управления контентом (CMS):

1. CMS на Stat.nic.ru – реализуется в RU-CENTER, здесь есть динамика по месяцам, данные даны с декабря 2013 года, анализируются семь CMS: Joomla!, WordPress, Drupal, MODx, “1C-Битрикс”, NetCat, UMI.CMS. Теория и практика, стоящие за этой статистикой, подробно описаны, для соответствующего робота создана информационная страница. (Да, оговорюсь, на всякий случай: я имею прямое отношение к этому проекту.)

2. CMS на StatOnline.ru – проект REG.RU, есть динамика по месяцам, данные даны с апреля 2013 года. CMS здесь заявлено гораздо больше, а именно – 20. Описание методики, какие-то подробные статьи с анализом собранной статистики CMS, найти пока не удалось. Это не очень хорошо. Тем не менее, числа, по совпадающим CMS, близки к полученным в исследованиях Stat.nic.ru.

3. iTrack.ru – рейтинг iTrack, появившийся самым первым из упомянутых в этой записке. Динамики по месяцам нет, исследование, насколько можно понять, проводится редко. Недавно появился отчёт за первое полугодие 2013 года. Числа близки к показателям двух других источников. На сайте есть очень краткое описание методики. К сожалению, это описание содержит досадные технические неточности, которые авторы никак не исправят. Например, там фигурирует такая фраза: “В ходе исследования учитываются домены, ответившие в течение 20 секунд на запрос по адресу http://domain.ru.” Очевидно, домены не могут отвечать на HTTP-запросы, это делает веб-сервер.

Есть ещё рейтинги CMS, составляемые при помощи опроса веб-студий. Но это совсем другая выборка, мало что говорящая о технологиях, реально использующихся в Рунете.

Роскомнадзор утвердил “Рекомендации по ограничению операторами связи доступа к сайтам в сети Интернет с запрещенной информацией”. Сами рекомендации тоже опубликованы на сайте (формат Word .DOC – хотя, конечно, хотелось бы видеть RTF, ну да ладно). Кратко: блокировать рекомендовано не по IP, а по URL, только “на сетях доступа”, то есть, за исключением транзитного трафика. Выделение URL должна проводить система DPI. Собственно, вариант весьма разумный, и, да, это те рекомендации, которые публиковались раньше. Теперь посмотрим, как их будут внедрять.

(А VPN, HTTPS и прочие штуки – давайте оставим за скобками.)

Кстати, для сбора и чтения RSS-лент, в качестве замены закрытому Google Reader, я установил Tiny Tiny RSS (TT-RSS). Пока что этот инструмент, который нужно “хостить” самостоятельно, выглядит очень неплохо. Установился без проблем, настройка также трудностей не вызвала. Работает под Apache+PHP+MySQL, на виртуальном сервере под Linux. Пакет обладает приличной гибкостью, можно настроить под свои привычки. Например, Tiny Tiny RSS умеет генерировать ежедневный дайджест из сообщений RSS-лент и присылать его почтой. На мой взгляд, одна из самых полезных функций.

До того, как установить TT-RSS, я некоторое время использовал The Old Reader – это “внешний” сервис, который выглядел весьма привлекательно, так как, фактически, просто повторял полезные функции Google Reader. К сожалению, The Old Reader сломался. Совсем. Сейчас они показывают котиков. (Это такая находка, недурная, надо сказать: на странице, сообщающей о недоступности сервиса, размещаются изображения котов. Проблема в том, что котики там показываются уже много дней, так как разработчики хрестоматийным образом потеряли свои базы данных, и, похоже, проект на этом завершился. Жаль.)

Update: как подсказывают в комментариях, The Old Reader вернулся. Это очень хорошо. Если разработчикам удастся достичь некоторой минимальной разумной надёжности, то этот проект можно будет рекомендовать.