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

Предположим, что в не самом далёком будущем, году эдак в 2072, атомные реакторы, вырабатывающие электроэнергию, находятся прямо внутри крупных городов, заменяя собой распределительные подстанции масштаба квартала или многоквартирного высотного жилого комплекса. Как такое стало возможным?

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

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

(Источник иллюстрации.)

Сделал вот такую страничку: DNSSEC.PW. Планирую там собирать всякие полезные ссылки на публикации, утилиты, справочные материалы, связанные с DNSSEC.

Обновил раздел “Избранные записки” – кое-что добавил.

Штатовская история, начавшаяся с информации о возможной записи всех телефонных разговоров на уровне операторов, – развивается: теперь обсуждают неограниченный доступ NSA к информации крупнейших интернет-сервисов, в том числе, к электронной почте и другим пользовательским данным. Занятно, что сами компании уже отрицают, что предоставляют “доступ к серверам и аккаунтам”. Возможно, оно так и есть.

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

Поэтому, вероятно, используется другая, вполне традиционная, схема: сетевой трафик полностью зеркалируется в системы DPI, используемые NSA, а дальше агентство разбирает этот трафик самостоятельно. Естественно, напрашивается вопрос: как быть с шифрованным трафиком (HTTPS и т.п.)? Ответ на него такой: зеркалируются и ключи, в том числе, сеансовые, если речь идёт о нормальных реализациях HTTPS. Сделать это не так сложно, потому что часто в нагруженных системах массового обслуживания защищённый канал оканчивается на специальном шлюзе, а внутри сети сервиса трафик ходит в открытом виде. Соответственно, при необходимости, никто не мешает передавать по открытой сети и сеансовый ключ (понятно, что обычно это не требуется – трафик и так открыт).

Добротные аппаратные DPI-решения для анализа интернет-трафика сейчас доступны даже для обычных коммерческих компаний. Очевидно, у АНБ с такой аппаратурой проблем давно нет. А доступ к серверам – нет, не требуется.

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

Понятно, что такой инструмент “ломает” DANE. (Напомню, что DANE привязывает, при помощи DNSSEC, SSL-сертификаты к домену.) Один из сценариев: интернет-провайдер подменяет в ответе DNS-резолвера цепочку подписей для домена, включая туда нужные записи DANE, показывающие на “подменный” SSL-сертификат. DANE рекомендует проводить проверку подписей DNS на клиенте, тем самым обеспечивается защита от подмены данных резолвером интернет-провайдера, однако в случае с “теневой зоной” никакой защиты нет: все подписи валидны, а сертификат получаем “подменный”. Более того, DANE, при условии подходящей браузерной реализации, тут позволяет использовать “недоверенный” (даже самоподписанный) сертификат, удостоверив его DNSSEC, что даже облегчает перехват HTTPS (потому что не нужно привлекать удостоверяющий центр).

Проблемы, подобные только что описанной, – это проблемы известные. И есть идеи о том, как проблемы преодолевать. Например, можно, следуя схеме SSH, записывать отпечатки ключей безопасного узла при первом соединении. Тогда подмену позднее можно обнаружить на клиенте, сверив отпечатки. (Конечно, возникают известные трудности со штатной сменой ключей.)

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

Конечно, у подобных систем есть свои проблемы. Например, они могут конфликтовать с геораспределёнными системами, которые по своим внутренним причинам отдают пользователям из разных регионов разные данные. Впрочем, эта особенность в большей степени касается SSL-сертификатов, чем DNSSEC.

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

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

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

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

ЦАГИ сообщает об испытаниях модели, сделанной по схеме “летающее крыло”:

“Специальная тематическая модель «Летающее крыло» с различными вариантами расположения двигателей и геометрии хвостового оперения была спроектирована и изготовлена в ЦАГИ в 2011 году. В прошлом году модель испытали в дозвуковых АДТ Т-102 и Т-107.”

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

В Музее Фицуильяма (Fitzwilliam Museum) хранится занимательный металлический многофункциональный нож, вроде швейцарского армейского: помимо клинка, инструмент имеет складную ложку, некие крючки и вилку. Ничего необычного, конечно. Кроме того, что этот инструмент с территории Рима датируют третьим веком нашей эры. Материалы: железо (клинок) и серебро. Скорее всего, если это третий век, то нож был весьма специальный, не имевший широкого хождения. Картинка ниже.

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

(Ссылкой на описание этого ножа поделился Александр Малюков.)

Статья про технологию DANE, которую я написал для “Открытых систем”, появилась в общем доступе на сайте – почитайте.

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

UPDATE (06.05.13) – статья доступна. UPDATE (03/06/13): по неясной мне причине, статью опять убрали в доступ по подписке. Окей, ладно, это право издателя.

Кстати, пока не закончился месяц май, вот записка шестилетней давности, рассказывающая о первом U-2, экстренно покрашенном под схему NASA.

В контексте проекта мониторинга CMS в Рунете часто спрашивают, как сопровождать робота, собирающего статистику по сайтам. Отмечу, что при большом числе запросов (а робот, опрашивающий CMS-ки, генерирует этих запросов десятки миллионов), важна каждая мелочь. Кратко поделюсь некоторым нашим опытом.

CMS определяются по сигнатурам. Конкретная сигнатура для веб-сервера строится на основании анализа его ответов на специальный набор запросов. Естественно, сама методика опроса серверов должна быть оптимизирована в плане нагрузки. Например, там где только возможно, используются не GET-запросы, а HEAD. Также ограничен разумной величиной поток запросов на конкретный веб-сервер.

Робот корректно представляется в User-Agent. В нашем случае вот так: “Web-Monitoring/1.0; +http://monoid.nic.ru/”. Здесь присутствует адрес в корпоративном домене, под которым находится веб-страница с максимально подробным описанием того, что это за “зверь” забежал на ваш сайт. Почитайте: monoid.nic.ru. Практика подтверждает, что такая страница – необходимый элемент: она снижает обеспокоенность веб-мастеров.

Для IP-адреса, с которого ходит робот, обязательно нужна заполненная обратная зона, с говорящим именем, расположенная в том же узнаваемом корпоративном домене. В нашем случае это monoid-srv.nic.ru. Корректная обратная зона приветствуется не веб-мастерами, но админами и инженерами NOC-ов. (Да, возможно, с точки зрения внешнего наблюдателя, идеально было бы держать веб-сервер с информационной страницей на том же IP, с которого ходит робот, но технологически добротная реализация этого варианта слишком уж затратна.)

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

(А подробное описание методики с оценкой точности, подготовленное Артемием Ломовым, тоже опубликовано на stat.nic.ru.)