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

Интересный исторический обзор про разработку и полёты U-2 опубликован на сайте The National Security Archive. Даны подробные, с картами, описания полётов, в том числе, над территорией Советского Союза. Обсуждаются некоторые результаты. Познавательно.

Впрочем, по самому известному полёту, 1 мая 1960 года, план которого существенно перекроила советская ПВО, ничего особо нового нет. Ну, кроме очередных подтверждений тому, что грамотное использование советской стороной ситуации со сбитым U-2 привело к возникновению приличной сумятицы во всей штатовской программе разведывательных полётов. Кстати, довольно показателен и тот факт, что сам провальный полёт U-2 разрешили именно под воздействием заявлений Н. С. Хрущёва об успехах советской ракетной программы.

(Помимо прочего, как пишут на странице National Security Archive, публикацией этих документов ЦРУ официально признало существование одного очень популярного объекта – Area 51. Приводится даже его схема. Правда, эта самая сверхсекретная зона под номером 51 уже несколько десятков лет не сходит с киноэкранов и книжных страниц, ну да то всё были неофициальные сведения, да.)

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

1. Беспилотник может осуществлять полёт по маршруту. Это маршрут протяжённостью до 100 км (и более), а типичная дальность – 50 км. Скорости – от нуля до 100 км/ч (причём, скорость 100 км/ч хоть и является редким показателем на практике, но уж точно не строгий предел). Естественно, время полёта зависит от выбранной схемы беспилотника. Наибольшей практической дальностью обладают беспилотники классической “самолётной” конфигурации. По времени полёта (но не всегда по дальности) всех превосходят дирижабли. Правда, они не так популярны. Различные “коптеры” тут оказываются в проигрыше. Преимушество последних в другой характеристике – они могут зависать и осуществлять полёт на минимальной скорости. Да, то же самое способны предложить дирижабли, но последние сильно пригрывают по динамическим характеристикам.

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

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

2. Беспилотник может передавать на наземную станцию не только базовую телеметрию, но широкий поток данных, включающий видеоканал, а иногда и не один. Здесь есть разные решения, самым универсальным среди бюджетных является использование доступной сети GSM (3G/4G). Кроме того, есть готовые радиопередающие высокочастотные модули достаточной мощности и разумного веса. Однако, если речь идёт о поддержании широкополосной связи на расстояниях в десятки километров, с этими радиопередатчиками возможны дополнительные проблемы, связанные с регулированием использования радиочастотного спектра.

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

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

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

Не составляет труда разместить на борту простую инфракрасную камеру и блок ИК-подсветки (можно даже переделать под ИК-режим обычную цифровую камеру, правда, результат будет, так сказать, ограниченным). А вот качественный тепловизор – он, пока что, существенно за пределами бюджета энтузиаста. Вопрос – надолго ли?

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

Кстати, эта доставка, в сочетании с первым пунктом нашей подборки (“полёт по маршруту”), – самый острый момент в плане задач регулирования доступности беспилотников.

5. Беспилотник может записывать самые разнообразные дополнительные сведения, не только видео- и аудиосигналы. Сейчас доступны всевозможные сенсоры, датчики и готовые наборы, вроде лазерных дальномеров. Миниатюризация, опять же, помогает напичкать беспилотник инструментами фиксации физических характеристик окружающих объектов, а не ограничиваться только записью, скажем, сигналов WiFi. Идей здесь много, но это, наверное, другая история.

На фото – ночная посадка F-35B на борт универсального десантного корабля USS Wasp:

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

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

Вот, 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-сертификат не самоподписанный.