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

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

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

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

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

Подборка записок о подводных лодках:

• Подводные лодки: слежка и обнаружение;
• Связь подводных лодок;
• Гидроакустическая маскировка;
• Подводная навигация, ракеты, проблема автономности;
• Сообщения для подводных лодок: буи.

(Зарисовка, которую я написал в октябре 2013 года, но, думаю, можно её в воскресенье декабря 2014 тоже разместить.)

Из разговоров в коридоре :

– Ты уже разобрался с управляющими компаниями для накопительной пенсии?
– Нет. И не собираюсь.
– Почему?
– До пенсии осталось двадцать лет. Слишком многое может измениться.
– Хм. Ну и чем же ты тогда собираешься зарабатывать, став пенсионером?
– Отстреливать киборгов, а добытые чипы реализовывать через скупщика, на блошином рынке в развалинах ГЗ МГУ.
– ?!
– По лицензии. Конечно, по лицензии. В соответствии с постановлением Сияющего Конгломерата.

Поделюсь настройками TLS на веб-сервере dxdt.ru. Я использую связку Apache+mod_ssl (стандартное решение). Важнейшие параметры – это используемые протоколы, “шифронаборы” (Cipher Suites – часто переводят как “наборы шифров”), а также их приоритет. Например, сейчас не рекомендуется использовать SSLv3 (и более ранние версии, которые, конечно, экзотика, но всё ещё встречаются в “живой природе”). Соответственно, в ssl.conf (файл конфигурации mod_ssl) для хоста dxdt.ru указаны следующие строки:

SSLProtocol -ALL +TLSv1 +TLSv1.1 +TLSv1.2
SSLHonorCipherOrder on
SSLCipherSuite “EECDH+AESGCM EDH+AESGCM EECDH+AES EDH+aRSA !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4”

Первая директива (SSLProtocol) разрешает только TLS (в трёх версиях, как несложно догадаться). Протоколы семейства SSL – не поддерживаем. Вторая директива (SSLHonorCipherOrder) указывает, что mod_ssl должен использовать приоритеты наборов шифров, заданные сервером (а не клиентом, то есть браузеру не удастся навязать свои предпочтения).

Директива SSLCipherSuite – это самое сложное место в настройках. Она определяет допустимые криптографические наборы (“шифронаборы”: алгоритмы обмена ключами и аутентификации, шифр, режим шифрования, алгоритм дайджеста). Условные имена наборов разделены пробелами. Конкретный набор согласуется клиентом и сервером во время установления соединения. Если договориться о подходящем наборе не удалось – TLS-соединение не устанавливается (именно это и происходит в случае IE8 под Windows XP).

В mod_ssl используются сокращённые имена для обозначения групп шифронаборов. Например: EECDH+AESGCM означает, что для генерации сеансового ключа будет использоваться алгоритм Ephemeral elliptic-curve Diffie-Hellman (разновидность алгоритма Диффи-Хеллмана на эллиптических кривых), а в роли алгоритма шифрования выступит AES в режиме GCM (Galois/Counter Mode – Режим счётчика с “аутентификацией Галуа”: один из современных “продвинутых” режимов блочных шифров, обеспечивающий, в том числе, аутентификацию данных; Галуа там возникает потому, что алгоритм аутентификации работает в конечном поле).

Сайт dxdt.ru использует серверный сертификат с ключом RSA; соответственно, аутентификацию сеансовых ключей можно проводить только при помощи криптосистемы RSA. Это некоторым образом экономит нам пространство в конфигурационной строке mod_ssl: вовсе не обязательно вписывать туда подробные указания вроде EECDH+ECDSA+AESGCM, как нередко рекомендуют, – DSA всё равно не поддерживается.

Несложно догадаться, что подстроки в SSLCipherSuite, начинающиеся с ‘!’, обозначают запрет на использование определённых криптосистем или криптографических примитивов. Всегда полезно прямо запретить заведомо неподходящие алгоритмы. Отмечу, что, в соответствии с современными традициями, запрещён RC4 (хотя он всё равно не предлагался бы сервером с указанными шифронаборами – не подходит).

Update (23/12/2014): в комментариях подсказали изящный вариант, с отключением всего ненужного одной директивой -ALL в SSLCipherSuite; такой вариант требует более точного описания шифронаборов, но зато он лаконичен:

SSLCipherSuite “-ALL:EECDH+aRSA+AESGCM:EDH+aRSA+AESGCM:EECDH+aRSA+AES:EDH+aRSA+AES”

(Обратите внимание, что пробелы заменены на двоеточия.)

В HTTP-ответ добавлено поле HSTS (HTTP Strict Transport Security – требование “принудительной безопасности” для HTTP):

Header add Strict-Transport-Security “max-age=15552000”

Данное поле означает, что, грубо говоря, браузер должен запомнить, что к данному сайту доступ необходимо осуществлять только по HTTPS, в течение времени, указанного в параметре max-age поля HSTS. Это позволяет защититься от множества атак, основанных на подмене протокола HTTPS на HTTP.

Вот. Так работает TLS на dxdt.ru.

На снимке, собранном из четырёх фотографий аппарата Rosetta, – комета Чурюмова-Герасименко, достаточно крупным планом:

Источник фото – блог ESA, там же есть некоторые подробности и комментарии (англ.)

На фото – штатовский истребитель F-35C, во время испытаний:

(Фото: Lockheed Martin.)

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

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

Неясно, как так могло получиться, но атаковавшим ICANN удалось получить администраторский доступ к некоторым сервисам. Это удивительно потому, что авторизация в системах подобного уровня должна бы быть защищена от простого перехвата почты сотрудников. Хотя, конечно, никто не застрахован от ошибок. В итоге, из сервиса Centralized Zone Data System – это полезный инструмент, позволяющий получать файлы зон доменов New gTLD, – утекли контактные данные пользователей, а также пароли, но в хэшированном виде.

(Кстати, самое громкое дело было бы, если бы у ICANN, а точнее – у IANA и VeriSign, утянули бы секретный корневой ключ KSK от DNSSEC. Понятно, что, в текущей ситуации с поддержкой DNSSEC, катастрофы бы не случилось, но случай был бы весьма показательный. Дело в том, что до сих пор не разработана процедура ротации корневого ключа KSK, так что DNSSEC, разве что, оставалось бы просто выключить.)

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

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

С DNSSEC связано немалое число хитрых особенностей, которые не так очевидны, как базовые принципы этой технологии. Например, часто приходится сталкиваться с неверной трактовкой назначения DS-записи. Между тем, DS-запись (Delegation Signer) – важнейший элемент DNSSEC, так как с её помощью выстраиваются цепочки доверия. Эта запись указывает на ключ, который зона, расположенная на уровень ниже (делегируемая зона), должна использовать для удостоверения (подписывания) адресной информации.

Одна из хитростей состоит в том, что если в родительской (делегирующей) доменной зоне присутствует DS-запись для дочерней (делегируемой) зоны, и родительская зона безопасна (то есть, подписана DNSSEC), то это означает, что дочерняя зона тоже должна быть безопасной. То есть, валидирующий резолвер ожидает, что дочерняя зона содержит, во-первых, подходящие к DS ключи, нужные для проверки подписей, во-вторых – сами подписи на ответах об адресации внутри зоны. Соответственно, если DS-запись присутствует, а дочерняя зона не подписана, валидирующий резолвер будет возвращать сообщение об ошибке. Это совершенно правильное поведение, потому что иначе смысла в DNSSEC нет: подделать ответы без подписей не составляет труда; если резолвер не имеет возможности отличить подписанную зону от неподписанной по наличию DS-записи в доверенной (безопасной) зоне, то подписи можно вообще не проверять.

Другой важный момент: если авторитативный сервер родительской (делегирующей) зоны, подписанной DNSSEC, отвечает на рекурсивный запрос списком NS-ов и DS-записью, то подпись ставится только на значение DS. Казалось бы, нужно подписать и список NS-ов – как иначе узнать, что они правильные? Но если у нас есть доверенная DS-запись, то нет разницы, с каких серверов мы получим дополнительную информацию: главное, чтобы совпал ключ и его отпечаток в DS, а также сошлись значения подписей. Тут работает основной принцип DNSSEC: если данные об адресации аутентифицированы, то не имеет значения, из какого источника они получены.

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

Google Public DNS для зон, имеющих DS-запись, но не подписанных, возвращает ошибку (SERVFAIL), вне зависимости от того, какова природа этих DS-записей. Другие валидирующие резолверы ведут себя иначе. Например BIND, обнаружив неизвестный алгоритм генерации DS, считает, что DS-записи в родительской зоне вовсе нет (что не совсем корректно, но с практической точки зрения оправдано, и, конечно, соответствует рекомендациям RFC). Пример такого поведения можно наблюдать для зоны dotsu.su – здесь в .su специально указаны DS-записи с неизвестным алгоритмом (9).

На фото ниже – момент подготовки космического корабля Orion к установке теплового щита. Собственно, это часть корабля, обитаемый модуль. Можно разглядеть особенности конструкции и размещения агрегатов.

(Исходное фото: Lockheed Martin.)

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

• Интеллектуальные помехи комплексам ПВО;
• “Малозаметные” радары – преимущество приёмника;
• Сигнатуры, ПВО и утечки информации по побочным каналам;
• Радиолокация и уязвимости DNS;
• Бистатическая радиолокация против астероидов.