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

У ICANN опять новый сайт: icann.org. Судя по всему, традиционно сделан на Drupal (версия 7). И это правильно. А кроме того, показательно, в свете рунетовского рынка веб-разработок, где до сих пор не перестали изучать распространение “закрытых” коммерческих CMS-ок (а их мизерное количество) и сравнивать, рейтинговать их популярность.

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

Автор теста – Артемий Ломов.

Вот даже Алекс Экслер в Испании подключается к “соседскому” открытому Wi-Fi, и исследует сетевые сервисы (я надеюсь, при помощи специально сконфигурированного ноутбука). А вы говорите! Что же ожидать от простых пользователей? Они тоже подключаются куда попало. В том числе, и всякими смартфонами, в которых куча персональной информации.

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

А потом удивляются, что почту взламывают.

(Ага, это юмор по выходным.)

Кстати, обсуждение заметки про VPN в чужих сетях, навело на другую интересную мысль. Учитывая, что устройств, использующих доступ к Интернету, при себе всё больше, логичным решением для, например, отеля, является своя точка доступа Wi-Fi с тем же самым VPN-ом, засунутым внутрь. Должно быть удобно, потому что позволит использовать даже те устройства, которые с OpenVPN не дружат.

Чтобы проверить решение на практике, я взял валявшийся без дела роутер Wi-Fi ASUS RT-N12, залил в него прошивку DD-WRT, с поддержкой OpenVPN, загрузил сертификаты (там есть панелька в веб-интерфейсе даже, можно не браться за консоль) и – всё работает, благо, внутри у него Linux. Сложностей настройки не выявил. То есть, теперь сценарий такой: подключаем к чужой проводной сети (Ethernet, понятно) роутер, он поднимает внутри VPN, и получаем собственный зашифрованный и безопасный Wi-Fi, через который могут работать и смартфоны, и планшеты, и старый КПК. Удобно.

В продолжение истории Trustwave – компании, которая призналась, что выпускала SSL-сертификаты, предназначенные для скрытного прослушивания трафика HTTPS: Mozilla распространила весьма строгое по форме требование к удостоверяющим центрам, чьи корневые сертификаты встроены в этот популярный браузер. Цитата:

We have requested that any such certificates be revoked, and their HSMs destroyed. We have requested the serial numbers of those certificates and fingerprints of their signing roots so that we, and other relying parties, can detect and distrust these subCA certificates if encountered. We have requested that any CAs who have issued subCA certificates fulfill these requests no later than April 27, 2012.

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

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

Другое дело, что только в прошлом году вся эта история с практикой SSL/TLS стала активно обсуждаться в популярных СМИ, а не только в забитых всякой математикой специализированных списках рассылки, которые мало кто читает. Теперь вот довольно-таки паникёрское заявление сделала Mozilla. Интересно, какую реакцию можно ожидать? Что, известные УЦ повинятся? Сдадут свои сертификаты? Перестанут сотрудничать с крупными и очень влиятельными клиентами? Что-то с трудом верится. Тем более, что отловить “кривые” сертификаты довольно трудно, они не светятся на весь Интернет, а пользователь, даже высококвалифицированный, столкнувшись с таким сертификатом, не сможет его распознать. Сейчас нельзя просто взять и выкинуть из браузеров корни всех тех УЦ, которые не смогли убедить разработчиков в том, что они белые и пушистые, подорвав тем самым бизнес этих УЦ – есть риск, что тут будет усмотрено нарушение законов о защите конкуренции. Просматривается, так сказать, полезный выход – это разработка новой технологии управления доверием в Интернете, и такая технология, вероятно, должна быть распределённой, ориентированной на пользователей. Собственно, об этом тоже сказано в исходном сообщении Mozilla. Но возможен и вариант, когда пользователи просто начинают доверять другому корню, скажем, корню DNS.

А если вернуться в сугубо практическое русло, то нужно сказать, что криптография пока что не сломана. Если использовать собственную инфраструктуру ключей и сертификатов, то перехватывать трафик “специальные” сертификаты других УЦ не позволят.

Ну и развитие истории подтверждает то, что производители браузеров всерьёз занялись игрой на рынке безопасности.

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

Я, впрочем, использую VPN. Это хорошее со всех сторон решение. Посудите сами, в случае с чужой сетью, можно выделить два разумных “канала утчеки” или “направления атак”, – называйте, как хотите. Первый канал: ваш сетевой трафик, связанный с типичным использованием сервисов Интернета (страницы сайтов, электронная почта и так далее). Второй канал, о котором обычно забывают: DNS – позволяет отправить ваш трафик куда угодно, буквально, куда угодно; чем и пользуются, обычно, правда, в “благих” целях, например, для того, чтобы предложить оплатить доступ. Да, есть HTTPS. Но это, на мой вкус, полумера, к тому же, она не распространяется на DNS.

Технически решение выглядит вполне ожидаемо: виртуальный сервер из Amazon EC2, пакет OpenVPN и BIND, в качестве рекурсивного резолвера на том же сервере. В ноутбуке (на клиентах вообще) – Ubuntu (или другой дистрибутив) и тот же OpenVPN.

Не стану описывать детали настройки, на сайте OpenVPN есть подробное описание и примеры конфигурационных файлов, никаких проблем с тем, чтобы поднять сервер и настроить клиент не возникает. Более того, схема работает даже для клиентских машин под Windows, есть специальная оболочка.

Самый простой вариант настройки VPN это решение типа “точка-точка” с общим секретом (файл с ключом и для сервера, и для клиента). Решение простое, но малоинтересное. Например, потому, что нельзя реализовать одновременное подключение нескольких клиентов к серверу. Поэтому следует использовать вариант с сертификатами SSL. Естественно, покупать какие-то сертификаты для этого не нужно: берём OpenSSL и либо руками, либо при помощи скриптов от OpenVPN, генерируем всё, что нужно. А нужно: сертификат общего удостоверяющего центра, сертификат сервера, сертификаты для всех клиентов.

Другие особенности. Для VPN-сервера нужно взять фиксированный IP-адрес, это позволяет устанавливать соединение, не используя DNS. Я, впрочем, держу А-запись, указывающую на сервер. Так, на всякий случай. В конфигурационных файлах на клиентах, конечно, указан IP-адрес. Кроме того, на клиенте нужно указать и адрес собственного резловера (resolv.conf). Я использую тот же IP – VPN-сервера, потому что всё крутится на нём. На сервере в настройках BIND требуется дополнительно разрешить обработку рекурсивных запросов, приходящих от клиентов OpenVPN. А для того, чтобы трафик ходил наружу, нужно настроить NAT, в моём случае это делается при помощи правил в iptables.

Что мы получаем? Вот что: в результате весь трафик ходит через защищённый канал, который автоматически создаётся при подключении ноутбука к любой внешней сети. Есть потенциальная проблема с фильтрацией пакетов в чужой сети. Поэтому в качестве транспорта для VPN я использую TCP, ходящий на 80-й порт. Такое направление редко где закрыто, потому что, как известно, это HTTP от Веба, а Веб нужен всем. Есть и другие варианты: TCP и 443 (HTTPS) или даже “стандарт” – UDP и 1194, обычно работает.

Да, очевидно, что весь этот безопасный VPN заканчивается у точки выхода, которая, строго говоря, находится где-то внутри инфраструктуры амазоновского хостинга. Менее строго, за точку выхода можно принять “внешний” IP-адрес, выделенный виртуальному серверу. Именно под этим адресом трафик, покидающий VPN, виден другим узлам. То есть, защита заканчивается на сервере. Но такой расклад, на мой взгляд, куда более приемлем, чем вариант с хождением того же трафика в открытом виде через произвольные сети, неизвестно кем администрируемые.

(И, кстати, весь популярный “геотаргетинг” по IP-адресу – ломается. Например, “Яндекс” предлагает мне посмотреть карту Дублина и почитать дублинские новости.)

Занятно, что новые веб-технологии стороны клиента содержат всё больше и больше разнообразных “алгоритмических” добавок, работающих без всякого Javascript. Например, в технологии Media Queries есть логические выражения, преобразование которых проводит браузер, оперируя разными свойствами доступного окружения операционной системы (типа размера окна и так далее). Поделюсь парой полезных ссылок по этой теме, это статьи проекта WebHiTech:

• С удобством от устройства к устройству. Часть 1;
• С удобством от устройства к устройству. Часть 2.

А вообще, такое развитие – прямой путь к появлению всевозможных новых уязвимостей. Интересно, возникнут ли вредоносные программы, распространяющиеся исключительно внутри файлов CSS?

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

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

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

Хорошо известно, что если злоумышленник сумел получить доступ к удостоверяющему центру, то система доверия полностью разрушается, а пользователь, который вынужден по определению доверять сертификатам центра (они встроены в браузер!), оказывается даже в худшем положении по сравнению со случаем, когда SSL-сертификаты никто дополнительно не удостоверяет.

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

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

Вернёмся к теме: да, проблема тут в том, что Trustwave использовали своё положение “центра доверия” для того, чтобы поставлять систему, трактующую это “доверие”, мягко говоря, не так, как его трактуют в презентациях для владельцев веб-сайтов, которые приобретают SSL-сертификаты. С другой стороны, хорошо известно, что Trustwave не первые, и, возможно, не последние. А всё это лишь очередной громкий информационный повод для того чтобы “пересмотреть существующую систему”. Чуть ранее шумели вокруг “массовых взломов и хакерских атак на VeriSign” (а это вообще крупнейший провайдер “доверия” в действующей иерархии, даже DNS подписана с участием этой компании). Вокруг данных технологий существует заметный рынок и разные бизнесы, так что, похоже, заготовлено занятное продолжение.

Кстати, вот долгоиграющая тема – мимикрирующий под домен “Проверка.РФ” адрес http://проверка.рф⁄click.dxdt.ru/. Я завёл этот адрес в 2009 году, в демонстрационных целях. Надо сказать, что браузеры с тех пор сильно улучшились, данный “кривой” адрес отображают хорошо, в Punycode. А вот Google пока что не меняется. Как и раньше, на странице выдачи по запросу “Проверка.рф” домен отображается кириллицей, результат неотличим от адреса под настоящим кириллическим доменом верхнего уровня. Впрочем, про это я уже рассказывал полтора года назад, со скриншотом.

Домен .РФ продолжает уверенно терять вес. Новые правила удаления доменов сгладили процесс, но всё равно – ситуация уже хорошо видна на статистических графиках:

По этой же теме – пост о печальных прогнозах в блоге регистратора RU-CENTER.

Сообщают, что в браузере Chrome планируется отказаться от поддержки онлайн-проверки SSL-сертификатов на предмет отзыва. Соответствующие протоколы позволяют браузеру проверить, не отозван ли сертификат, который ему предъявляет тот или иной сайт при соединении по HTTPS. И такая проверка проводится непосредственно перед тем, как принять (или не принять) сертификат, с помощью запроса к специальному серверу.

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

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

Да, интересно наблюдать, как Chrome сперва вылез в браузеры-лидеры, а теперь начинает активно влиять на технологические традиции рынка.