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

Кстати, в октябре исполнилось пятьдесят лет самому “новому” из штатовских стратегических бомбардировщиков B-52. Серию закончили выпускать в 1962 году. До сих пор самолёты в строю, а срок службы планируют продлевать и дальше. Понятно, что модернизируют их частенько. Меняют всякое оборудование. Оснащают другим вооружением. Но платформа остаётся той же самой. На фото – B-52, под крылом которого подвешен экспериментальный гиперзвуковой ЛА X-51A. Возможно, через несколько лет место экспериментального аппарата займут серийные гиперзвуковые ударные беспилотники.

(via)

Многие спрашивали про поддержку DNSSEC российскими регистраторами. Вот, буквально только что, запустили такую поддержку RU-CENTER и R01. Причём, RU-CENTER поддерживает DNSSEC и для зон .com и .net (R01 – пока только .su).

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

Подробнее про DNSSEC на практике можно почитать на странице, размещённой под “демонстрационным доменом” nox.su, который, конечно, DNSSEC поддерживает.

Если у кого есть вопросы по данной технологии – пишите, можно почтой (адрес справа на этой странице), можно в комментарии.

Новый номер “Доменных имён” только начал распространяться на бумаге, а предыдущий, посвящённый истории Интернета, доступен в виде .PDF – почитайте.

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

Отправился в печать новый номер журнала “Доменные имена”. Этот выпуск будет доступен на конференции RIW-2012, на стенде RU-CENTER. Подробности приводить не стану, но, конечно, не обошлось без обсуждения темы “фильтрации Интернета”. Вот, поделюсь, пожалуй, картинкой:

На сайте Internet Society ведётся список ресурсов, поддерживающих новую технологию DANE. Сайтов там пока что не очень много. Это хорошо объясняется тем, что поддержка DANE пока отсутствует в браузерах. Есть только один плагин для Firefox, да и то – в альфа-версии. Большая проблема. Без браузерной поддержки DANE никому не нужен. Без DANE – DNSSEC теряет заметную часть технологической привлекательности, потому что только благодаря привязке к сайтам DNSSEC можно продвинуть на клиентскую сторону.

Согласно современной реальности Интернета, прорывом был бы качественный плагин для майкрософтовского браузера IE. У меня нет уверенности, что подобный плагин возможен для IE, так как я недостаточно знаком с архитектурой этого браузера. Если кто-то может рассказать подробности, то, пожалуйста, выскажитесь в комментариях. Ниже, я опишу логику работы плагина, вдруг, кто-то захочет его реализовать (что было бы замечательно).

Итак, DANE позволяет разместить в DNS отпечаток SSL-сертификата и проверить достоверность соответствия этого отпечатка домену при помощи DNSSEC. Для проведения проверки требуются: значение специальной записи из DNS и сертификат, предъявляемый веб-сервером. Сличение проводится, грубо говоря, по имени хоста. То есть, отпечаток из DNS для заданного хоста должен соответствовать отпечатку, вычисленному по полученному сертификату. Более подробное описание части, касающейся DNS, есть в записке про DANE.

Соответственно, плагин для браузера должен вмешиваться в процесс установления соединения по HTTPS с веб-сервером, получать отпечаток ключа сертификата, предъявляемого сервером и сверять этот отпечаток с данными, полученными из DNS, если их удалось получить и подтвердить DNSSEC-ом, конечно. Дальнейшее поведение плагина зависит от того, каковы результаты проверки:

• если валидный отпечаток из DNS совпадает с сертификатом, то браузер должен показать некий дополнительный флаг, означающий, что связка сертификат-сайт проверена DNSSEC. Если при этом сертификат самоподписанный или выдан неизвестным браузеру удостоверяющим центром (УЦ), то нужно подавить предупреждение браузерной системы безопасности (а можно ли это сделать в IE?);
• если отпечатки не совпали, то нужно, наоборот, выдать предупреждение системы безопасности, даже если сертификат валидный и подписан доверенным УЦ;
• если данные, полученные из DNS, не прошли проверку подлинности, а всё остальное – совпадает, то, опять же, нужно выдать предупреждение.

Плагину придётся самостоятельно проводить проверку подписей DNSSEC и извлекать их из DNS. В общем, задача не самая простая, но, вероятно, решаемая. Это я к тому, что, может, кто-то возмётся за реализацию.

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

(The Hidden Internet of Iran: Private Address Allocations on a National Network.)

На всякий случай уточню, что обсуждающиеся сейчас запреты VPN-ов и прочих “защищённых виртуальных каналов” коснутся, например, и SSH, и RDP. Поэтому нельзя будет администрировать серверы. Ну либо должна быть лицензия администратора, с соответствующим допуском. Занятно, да.

В Adobe обнаружили взломанный сервер, имевший доступ к ключам от сертификата, которым подписывается код продуктов Adobe для Windows и Mac-ов. Обнаружили после того, как получили две вредоносные программы, подписанные ключами Adobe.

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

(Да, в тексте по ссылке речь идёт не о краже ключей, а о неправомерном доступе к ним.)

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

Кстати, на упомянутом сайте есть и небольшой анализ данных логов.

Кстати, напомню, что на страницах dxdt.ru есть подробная инструкция по настройке собственного сервиса VPN, с использованием OpenVPN и иерархии SSL-сертификатов (собственные же).