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

В Штатах (1 мая) провели очередное испытание гиперзвукового летательного аппарата X-51A. Сообщают, что испытание удачное. Это последнее испытание для прототипа X-51A, следом за ним станут исследовать гиперзвуковой полёт при помощи других экспериментальных аппаратов. Напомню, что основная особенность этого направления развития реактивной техники в том, что аппараты имеют воздушно-реактивный двигатель, использующий для питания атмосферный кислород, поступающий через воздухозаборники – это сильно экономит топливо, но и создаёт кучу аэродинамических проблем.

X-51A, согласно отчётам, достиг скорости M=5.1 – как раз общепринятая граница гиперзвукового диапазона. Примем скорость звука равной 330 м/c, тогда получается, что аппарат летел со скоростью около 1600 м/с. То есть, пуля или снаряд уже не догонит, нужна ракета. Но вообще реальные преимущества начинаются со скоростей около M=7 и более – такой аппарат будет иметь для расстояния в 1000 км подлётное время порядка 7 минут, что совпадает, примерно, с временем принятия оперативных решений в типичной системе ПВО.

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

Я уже писал про программу X-51 раньше, и не раз, так как проекту несколько лет.

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

Очевидно, что каналы, по которым передаются управляющие команды, являются слабым местом, ограничивающим применение боевого робота: за линией фронта, на территории противника, связь могут заблокировать. Это ограничение в любом случае будут преодолевать, несмотря на готовящиеся запреты со стороны ООН.

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

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

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

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

И это не единственный сценарий атаки, который позволяет построить протокол UDP.

В качестве ответа очередной порции проблем с доступностью NS-ов в RU-CENTER ввели, в дополнение к уже существующим, серверы, построенные с anycast. Теперь должно стать надёжнее.

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

Действительно, анализ конкретных криптосистем, проводимый для собственных нужд разведки, должен быть засекречен. Через некоторое время секретность теряет смысл – документы, связанные с анализом, могут быть опубликованы. В документах есть математика, есть теоремы. Достаточно немного популярно изложить предмет – и вот вам “секретные теоремы высшей алгебры”.

Ну и не станем забывать о том, что многие результаты, легшие в основу современного “несекретного” математического аппарата криптографии, были параллельно получены в рамках вполне себе секретных исследований, выполненных профильными институтами спецслужб. Наиболее часто описываемый случай “секретных теорем” (не так важно, достоверный или нет) – криптосистема RSA: алгоритм, известный сейчас как RSA, на несколько лет раньше появления описаний в открытых источниках, предложил Клиффорд Кокс (Clifford Cocks), математик британского Центра правительственной связи (GCHQ), но его публикации держали в секрете до 1997 года.

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

(Я часто писал про DANE на dxdt.ru.)

DNSSEC удостоверяет информацию, размещаемую в DNS. Вообще, современное понимание DNS сильно шире простого преобразования “символьное имя <-> числовой адрес”. Эту систему рассматривают как распределённую базу данных, хранящую некие пары значений и снабжённую не менее распределённым механизмом для поиска. То, что при помощи DNS можно сопоставлять символьные имена хостов и IP-адреса – это лишь одно из применений полезного сервиса.

Например, существует такая ресурсная запись (то есть, пара значений из базы данных DNS) – SSHFP, SSH FingerPrint. Эта запись позволяет разместить в DNS отпечаток серверного криптографического ключа, используемого для доступа при помощи SSH. Зачем? Для того, чтобы SSH-клиент мог сверить данные, полученные при установлении соединения от сервера, с данными, размещёнными в DNS, и лишний раз убедиться, что всё в порядке, канал никто не перехватывает – или наоборот: перехватывает.

Для того, чтобы схема имела смысл, доменная зона должна быть безопасной, подписанной DNSSEC. Понятно, что подписанная зона удостоверяет IP-адрес, с которым будет устанавливаться соединение по SSH. Но DNS никак не гарантирует, что это соединение не перехвачено на уровне IP, и атакующий не подменяет сервер.

Включить проверку можно при помощи настройки SSH-клиента. Например:

$ ssh -o VerifyHostKeyDNS=yes test@example.com

(Понятно, что опцию VerifyHostKeyDNS можно просто указать в конфигах.)

Отпечаток, размещаемый в DNS, генерируется (в Linux-ах) при помощи следующей команды:

$ ssh-keygen -r dxdt.ru

Например, я держу такую запись в зоне dxdt.ru, которая, естественно, подписана DNSSEC. Выглядит запись так:

dxdt.ru. IN SSHFP 1 1 0A1D19C05D239CCE90EE616DEB2EF80B35F3759B

– посмотреть может каждый, опросив серверы, поддерживающие зону.

На мой взгляд, полезное применение DNSSEC.

На картинке, как пишут, “концепт” боевого беспилотника с вертикальным взлётом и посадкой от Lockheed Skunk Works.

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

Можно бы перевести dxdt.ru целиком на HTTPS, но WordPress что-то не готов – генерирует для изображений небезопасные ссылки. Вообще, с HTTPS есть ещё одна проблема: поисковики. Я замечал, что Google умеет не только ходить по HTTPS, но и индексировать такие страницы, а вот насчёт “Яндекса” есть сомнения. В любом случае, ссылки для поисковиков станут другими, так как придётся их роботов перенаправлять с http на https, что ботов не порадует. Можно, конечно, вообще на другой домен всё перенести. Но это, думаю, перебор. Поэтому пока останемся на HTTP, хоть это и прошлый век.

На stat.nic.ru – очередное обновление: большая статья с результатами исследования веб-технологий, используемых в Рунете, и их сравнением с международным сегментом Сети (тему в RU-CENTER ведёт Артемий Ломов). Данных много, поясняющего текста тоже немало. Рекомендую всем, кому интересно, как сейчас устроен рунетовский веб. Исследование, вообще говоря, уникальное.

ICANN принимает комментарии общественности по вопросу ротации корневого KSK, используемого в глобальной DNSSEC. Корневую зону DNS администрирует организация IANA (при участии VeriSign). Напомню, что для генерации подписей корневой зоне используют ключ ZSK (Zone Signing Key), который, в свою очередь, удостоверен подписью, полученной при помощи корневого KSK (root Key Signing Key). Этот последний KSK является неким самым главным ключом от DNS, встроенным в валидирующие резолверы, позволяющим строить “цепочку доверия”.

Криптографические ключи принято периодически менять. Занятно, что для корневого KSK за эти годы не было предложено стандартной процедуры ротации. Основная проблема состоит в том, что клиентские резолверы, которых уже существует большое разнообразие, могут не получить новый ключ. Многие из них настроены вручную и, несмотря на существование RFC5011, рискуют остаться со старым ключом, который станет непригоден для проверки подписей. Таким образом, валидация сломается, адреса перестанут работать, а те, кто использует валидирующие резолверы – опять разозлятся и отключат DNSSEC. Ну, возможно, отключат.

Комментарии по проблеме принимают до 31 мая. Эту дату могут и сдвинуть. Когда проведут ротацию ключей и каким методом – пока вообще не ясно. Скорее всего, будет отдельный проект и несколько рабочих групп. Это в традиции ICANN.