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

В продолжение истории 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-адресу – ломается. Например, “Яндекс” предлагает мне посмотреть карту Дублина и почитать дублинские новости.)

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

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

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

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

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

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

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

Потихоньку развиваю nox.su (это иллюстрация использования DNSSEC, которую я планирую показывать на семинарах по теме): дополнил описание, поменял ключи (теперь два ZSK, как положено), опубликовал файлы зон (исходный и с подписями). Как и раньше, все доступно на сайте.

Addon: вообще, как и ожидалось, по сравнению с поддержкой обычной доменной зоны, поддержка DNSSEC значительно сложнее. Более того, если говорить о корпоративном рынке, о рынке сопровождения веб-проектов, то DNSSEC сильно увеличивает шансы передачи поддержки DNS “на сторону”, к тем, кто будет предоставлять подобную услугу профессионально. И сейчас-то поддержка доменных зон довольно экзотическая вещь, с кучей малоизвестных тонкостей, которые готовы породить большие проблемы. А DNSSEC поднимает планку примерно на порядок.

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

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

• работа с клавиатурой, мышью;
• движение взгляда по экрану (скорость, способ чтения);
• методика поиска информации (ключевые слова, построение запроса);
• методика отбора информации (выделение слов, терминов и так далее);
• структура методов коммуникации (электронная почта, всякие IM).

Ну и, очевидно, придумают ещё всяких признаков.

На основе анализа перечисленных особенностей определяется индивидуальная сигнатура пользователя, которую в DARPA называют биометрической. Анализ может проводить ПО, установленное на компьютере локально. Ну а сама сигнатура служит для аутентификации. Одно из применений – дополнение к паролям, используемым при входе в систему.

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

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

Понятно, что есть куча других, не менее интересных, практических направлений использования столь замечательной технологии, если она будет создана. Пока что DARPA публикует только сообщение о том, что такие разработки требуются агентству. Исходный документ с описанием задачи – доступен на сайте FBO.

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

Вообще, всякие наводки/излучения, с которыми борются, защищая информацию, годятся для организации подобного скрытого канала. Просто достаточно естественную наводку не блокировать. Скажем, годится сеть электропитания компьютера: в таком случае принимающая сторона ставит “прослушивающее” оборудование на линию, а тот, кто информацию передаёт, просто просматривает определённые файлы на своём компьютере – всё как обычно. Понятно, что есть куча сходных ЭМ-вариантов: сигнал, транслируемый монитором; наводки от принтера и так далее.

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

Едва ли не идеальное решение – Wi-Fi. Источник достаточно мощный, частота высокая. Можно намеренно поставить жучок в точку доступа. Жучок подмешивает в сигнал “дополнительную нагрузку” – то есть, организует спланированную утечку, работающую без всякого вмешательства пользователя, который, как обычно, просто работает с документами на своём компьютере.

Наверняка, есть ещё немало занятных идей.

Есть большой комплекс технологических проблем, связанных с прослушиванием спецслужбами чужих подводных кабелей. Чрезвычайно сложно уже только установить оборудование для прослушивания: водолазам нужно работать на большой глубине, да ещё, возможно, в чужих территориальных водах, куда требуется скрытно прибыть и так далее. Для решения подобных задач используют специальные подводные аппараты, в том числе, большие подводные лодки. Интересно, что после того, как оборудование на кабель установили, возникает ещё одна большая проблема: как получать копируемую системой прослушивания информацию? То есть, а как, собственно, организовать утечку? (Кстати, по определению, утечка информации имеет место только в том случае, если информация попала к атакующей кабель стороне; само наличие постороннего оборудования утечку не создаёт.)

Транслировать под водой сигналы чрезвычайно сложно. Можно, конечно, вести запись, и периодически приходить, менять кассеты силами тех же пловцов. Но время реакции выходит слишком большим: многие перехваченные сведения успеют полностью потерять свою ценность. Секретные сведения, имеющие, так сказать, стратегическое значение на длительном отрезке времени, вообще не обязательно передаются по подобным кабелям: есть же и другие средства связи. Так что отсутствие оперативной доставки информации сильно снижает привлекательность рискованной операции по установке подводного оборудования. Идеальным решением был бы ещё один кабель, протянутый прямо в центр сбора и обработки. Но кто ж подпишется под такой тривиальной схемой, выдающей установщика оборудования с головой?

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

Продолжим тему восстановления недоуничтоженных шредером документов. В комментариях к прошлой записке jno подтверждает, что восстановить простую “лапшу” – возможно. Напомню, что “лапша” – это вариант, в котором шредер разрезает лист на множество одинаковых узких полос, в одном из направлений, например, вдоль. Вообще, почему-то часто в ответ на вопрос о том, сколько вариантов потребуется перебрать для восстановления документа, разрезанного на n аккуратных полосок, приходится слышать о числе n! – очень много, да. Естественно, если бы это было так на практике, то для уверенного уничтожения оказалось бы достаточно резать листы вдоль на, скажем, 29 полосок (любой ширины, заметьте!). К счастью исследователей мусора, всё обстоит иначе, и факториал, задающий верхний предел для перестановок полосок, тут не играет решающей роли.

Из-за того, что в исходном документе содержится некоторая дополнительная структура, для восстановления не нужно перебирать все варианты перестановок. Так, если вы можете точно определить, что две данные полоски были (или не были) соседними (даже без выяснения правый или левый “сосед” обнаружился), то сложность восстановления всего документа из “лапши” не превысит n². Занятно, что восстановление чистого белого листа оказывается более проблематичным, чем листа с текстом. Если, конечно, предполагать, что в качестве опорной структуры используется начертание букв и строк текста (или некий рисунок). С другой стороны, зачем восстанавливать чистый лист?

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

И, конечно, можно устроить шредер так, что восстановить документ будет невозможно: достаточно измельчать бумагу в труху, пусть и механическим способом.

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

Состязание началось 27 октября, а ответы на все пять головоломок от команды-победителя были получены 2 декабря. Недолго, если учитывать, что как минимум две задачи выглядят довольно сложными из-за тщательности “уничтожения” исходного документа. В общем, очередной раз подтвердился хорошо известный факт: для уничтожения бумажного документа – его нужно дотла сжигать в камине (ну или в особой бочке, ага). Да. И тщательно измельчать образовавшийся пепел.

Подробности и исходные задачи – на специальном сайте.

Спустя примерно месяц, я вновь собрал SSL-сертификаты с серверов, на которые указывают домены .ru. Методика описана в прошлой записке по этой теме. Кратко повторю основные моменты: на первом этапе делается попытка определить адрес сервера (A-запись) для каждого из делегированных доменов (учитывая www.) в зоне .ru; из найденных серверов с уникальными IP выбираются те, у которых открыт 443-й порт (https); на заключительном этапе каждый из отобранных серверов опрашиваются на предмет SSL-сертификатов путём открытия https-сессии; собранные сертификаты разбираются при помощи OpenSSL.

В результатах “много цифр”, поэтому прячу под “Читать полностью”.

Читать полностью

Очень удобно, когда имя сети Wi-Fi (SSID) говорит само за себя, то есть, содержит прямое указание на “административную” принадлежность: avtosalon-gorod, bank-takoyto, cafe-apelsin. У удобства есть обратная сторона: всякие современные мобильные устройства, поддерживающие Wi-Fi, пытаясь найти знакомую точку доступа, передают в эфир имена сетей, к которым они раньше подключались.

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

(Кроме того, список известных устройству сетей, очевидно, годится для того, чтобы это устройство заманить в специально подготовленную сеть.)