Год 2016, новый

Заканчивается и 2015 год. Следующий, что логично, 2016. За прошедший год на dxdt.ru получился некоторый тематический перекос в сторону интернет-технологий: про авиацию и близкие технические области – публикаций стало меньше. (Да, собственно, частота публикаций вообще несколько снизилась.) В следующем году планирую ситуацию поменять, но, впрочем, посмотрим, как оно получится.

По традиции – несколько ссылок на записки из 2015 года:

С наступающим Новым годом!



Комментарии (6) »

Так как появились странные (невнятно сформулированные) слухи о недоступности DNS от Google из Рунета, я померил доступность при помощи сервиса RIPE Atlas – доступ есть, вот результат, на карте:

Atlas Google DNS

Измерение я проводил для 8.8.8.8, через 252 RIPE-зонда (probes), расположенных в Москве и ближайших регионах, в качестве запроса использовалось имя iana.org. Полученный адрес (верный) указан в легенде на картинке.



Комментарии (2) »

HPKP (HTTP Public Key Pinning) – технология, позволяющая привязать к серверу открытый ключ. Для этого служит специальное поле в заголовках HTTP. Я писал про HPKP на dxdt.ru ранее. Как и в случае практически любой технологии обеспечения информационной безопасности – интересно посмотреть, как реализация работает в деталях. Для этого я добавил HPKP на “тестовую площадку”: 1d.pw.

Напомню, кратко, как эта технология работает. При первом визите на сайт по HTTPS браузер запоминает отпечаток некоторого ключа, который передаётся в заголовке; это может быть отпечаток серверного ключа (так, например, сделано на dxdt.ru) или любого другого ключа, входящего в цепочку валидации сервера (можно добавлять ключи сертификатов удостоверяющих центров и так далее). При повторном соединении с сайтом по TLS браузер проверяет, что какой-то из ключей, предъявленных сервером, соответствует ранее записанному отпечатку. Если найти такой ключ не удалось, выдаётся сообщение об ошибке и соединение не устанавливается (именно этот вариант воспроизведён на тестовой площадке). Ситуация напоминает случай, когда браузер не смог провести успешную валидацию цепочки SSL-сертификатов, с той лишь разницей, что привязывание ключа позволяет защитить соединение от перехвата при помощи валидных сертификатов.

Отлаживать HPKP непросто. Запись отпечатка производится только в том случае, если браузер успешно установил соединение по TLS и получил ответ с корректно форматированным полем Public-Key-Pins – то есть, требуется работающий по TLS веб-сервер с валидным SSL-сертификатом. Для того, чтобы вызвать ошибку проверки отпечатка также требуется валидный сертификат: иначе браузер выдаст сообщение об ошибке раньше, чем доберётся до проверки отпечатков. При этом требуется серверный сертификат, выпущенный для другого ключа, отличающегося от “правильного”. Как-то узнавать браузер на сервере, чтобы имитировать подмену ключа, – не получится: проверка отпечатка происходит на самом раннем этапе установления TLS-соединения, ни куки-файлы, ни какие-то ещё данные “уровня приложения” к этому моменту переданы не будут. Идентифицировать по IP-адресу в наше время NAT-ов и прочих трансляторов – тоже неправильно.

Я поступил следующим образом. По адресу https://1d.pw/ откликается веб-сервер, который передаёт заголовок с отпечатком ключа и флагом, обозначающим, что отпечаток действителен для всех поддоменов (ниже я привожу поле Public-Key-Pins для 1d.pw полностью). А по адресу https://pin.1d.pw/ – откликается другой виртуальный хост, который использует другой серверный ключ (но в паре с валидным сертификатом). Если ваш браузер ещё не был на 1d.pw, то вы можете с его помощью успешно посетить pin.1d.pw. Однако если ваш браузер зайдёт на https://1d.pw/, то он запомнит отпечаток ключа. Если после этого попытаться открыть https://pin.1d.pw/, то должно появиться сообщение об ошибке (“невозможно установить защищённое соединение” или подобная формулировка) – это означает, что HPKP поддерживается браузером. Время жизни отпечатка указывается в поле Public-Key-Pins – для 1d.pw это 3600 секунд (или 1 час).

Вот заголовок HPKP:

Public-Key-Pins:pin-sha256=”afLVIYy6nD4LIkratYg295p89kYfqChllWQGYs7K8/A=”; pin-sha256=”K/QRriVzZo54i+9qeLPgP+22zWsL4rMZGFU9F0QJn/M=”; max-age=3600; includeSubdomains; report-uri=”http://hpkp-reporter.dxdt.ru/api/hpkp.pl”

Здесь есть ещё один интересный элемент – report-uri. Это адрес, по которому браузер передаёт сообщение о неудачной проверке отпечатка ключа (POST-запрос с данными в формате JSON). Я поднял отдельный обработчик для этих сообщений (планирую вынести его на другой домен и подключить, в том числе, к HKPK на dxdt.ru). Пока что данная функция работает только в Chrome, но это весьма распространённый браузер, поэтому, в теории, можно будет увидеть попытки перехвата TLS-соединений.

Посмотрим, как использование HPKP будет развиваться дальше.



Comments Off on Техническое: проверка HPKP в браузере

Первая ступень ракеты-носителя SpaceX Falcon 9 совершила успешную посадку, а сама ракета при этом успешно вывела на орбиту несколько спутников.

Credit: SpaceX

Всё это обещает существенное удешевление доставки на околоземную орбиту.



Комментарии (2) »

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

During a recent internal code review, Juniper discovered unauthorized code in ScreenOS that could allow a knowledgeable attacker to gain administrative access to NetScreen® devices and to decrypt VPN connections.

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



Комментарии (1) »

Zumwalt на море

В Штатах провели ходовые испытания нового эсминца Zumwalt. На фото ниже – установка надстройки на Zumwalt, 2013 год:

Zumwalt

(Фото: U.S. Navy.)



Комментарии (2) »

В среду с доменом MIL (это зона для военных структур США) приключилась глобальная проблема: сломалась цепочка DNSSEC, так как опубликованная в корневой зоне DS-запись не соответствовала ключу KSK, опубликованному в зоне MIL. Это означает, что валидирующий резолвер должен выдавать ошибку валидации – и ресурсы, размещённые в зоне, для клиентов такого резолвера оказываются недоступны. Как минимум, нарушилась цепочка, ведущая к глобальному ключу IANA. Интересно, что мало кто проблему вообще заметил, а чинили более 12 часов (связано с кешированием и регламентом обновления зон). Возможно, конечно, что внутри пентагоновских сетей используется другой корневой ключ и другой набор DNS-записей для валидирования – соответственно, их резолверы продолжали работать. На мой взгляд, более вероятно, что DNSSEC там на рекурсивных резолверах просто не используют, как и практически во всём остальном мире.

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



Comments Off on Техническое: домен mil. и DNSSEC

HPKPПолучается непрерывная серия записок про TLS и связанные технологии, но, тем не менее, продолжу. Добавил на dxdt.ru поддержку технологии под названием HPKP – HTTP Public Key Pinning. Key Pinning – это привязывание публичного ключа к сетевому ресурсу (по имени или по адресу) на стороне клиента. Принцип хорошо известен из практики использования SSH: здесь отпечатки, идентифицирующие серверы, при первом контакте сохраняются на клиенте; в дальнейшем, изменение отпечатка позволит обнаружить возможную подмену ключей в рамках атаки “человек посередине”. Для HTTP предложена технология (RFC 7469), базирующаяся на той же идее.

Веб-сервер передаёт специальное поле в составе заголовков HTTP. Поле содержит отпечатки (значение хеш-функции) публичных ключей, которые используются данным сервером при установлении TLS-соединения, а также время, в течение которого клиенту следует помнить отпечатки. Браузер (то есть, клиент HTTPS), впервые обнаружив отпечатки ключей, запоминает их. При следующих обращениях к данному ресурсу – отпечатки сверяются с переданными ключами: если обнаружено расхождение, то браузер не устанавливает соединение и выдаёт предупреждение системы безопасности. HPKP поддерживается, например, в Chrome и Firefox.

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

Посмотрим на реализацию подробнее, на примере dxdt.ru:

$ wget -S -O /dev/null https://dxdt.ru/ 2>&1 | grep ‘Public-Key-Pins:’ | tr -s ‘ ‘ | sed ‘s/\;/\;\n/g’

Public-Key-Pins: pin-sha256=”WXeGHAmPHRPwX7CbyIUCQm9mtStbVAZR2LOvTAAQKNg=”;
pin-sha256=”dj2qz8mxs8NSpJdISrUPRfL86ZGu3QNkJm4hL+opE0o=”;
pin-sha256=”nq9/zIb/QKb+tHd1ZU5keAYkYzrA8zx7tMmVtDDNG0M=”;
pin-sha256=”kkwURRddFrj4gRH7ILMp/Fqrvl6kfO4o2ekBOmiP6B0=”;
max-age=270127;

Поле HPKP называется Public-Key-Pins и, в нашем примере, содержит четыре значения pin-sha256 – это и есть отпечатки ключей (значение SHA-256 от публичного ключа, взятое в Base64). Почему их четыре? Потому что на dxdt.ru поддерживается два типа подписей: ECDSA и RSA, соответственно, нужно публиковать отпечатки для каждого из них; кроме того, стандарт требует указания как минимум одного “запасного ключа”, который отсутствует в цепочке валидации – я решил опубликовать по запасному ключу для каждого типа подписи. Итого: четыре отпечатка. Дополнительные отпечатки, очевидно, требуются для того, чтобы можно было поменять ключи без потери доступности сайта.

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

Параметр max-age – определяет (в секундах) время, в течение которого браузер должен сохранять отпечатки. Я, пока что, установил довольно осторожное значение: около трёх суток.

Кроме того, поле Public-Key-Pins позволяет использовать ещё пару параметров: includeSubdomains – это флаг, распространяющий действие отпечатков на поддомены; report-uri – адрес, на который браузер будет передавать сообщения об ошибках. Последний параметр особенно интересен. Он позволяет поднять сервер, который будет получать сообщения от клиентских браузеров, которые натолкнулись на ошибки в работе HPKP – это позволяет обнаруживать атаки “человек посередине”, что называется, в дикой природе. Сообщение содержит детали контекста, в котором возникла ошибка. Эту функцию уже реализует Google Chrome. Естественно, для приёма сообщений нужен отдельный домен. Создание такой точки приёма для dxdt.ru – следующий шаг: нужно выделить сервер и запрограммировать обработчик сообщений.

Addon:

Как получить отпечатки ключей? Достаточно просто, если воспользоваться OpenSSL (я использовал файлы секретных ключей).

Для RSA:

openssl rsa -pubout -in rsa-private.pem -outform DER | openssl dgst -sha256 -binary | openssl enc -base64

Для ECDSA:

openssl ec -pubout -in ec-private.pem -outform DER | openssl dgst -sha256 -binary | openssl enc -base64



Комментарии (29) »

Проект Let`s Encrypt, который позволяет в автоматическом режиме и бесплатно получать SSL-сертификаты, объявил о переходе в статус публичного бета-тестирования. Let`s Encrypt ориентирован на HTTPS и работает следующим образом: для получения сертификата на сервер, где этот сертификат будет использоваться, устанавливается специальное клиентское ПО (написанное на языке Python), это ПО взаимодействует с сервером удостоверяющего центра, подтверждает “владение доменом”, получает сертификат, настраивает локальную конфигурацию веб-сервера. В общем – автоматически выполняет все те действия, которые, как считается, отнимают у администратора сервера много времени, требуют специальных знаний и, тем самым, препятствуют массовому распространению HTTPS.

Инициатива, конечно, выглядит полезной. Но есть некоторые опасения. Так, клиент Let`s Encrypt требует рутовых прав для исполнения своих функций. Не удивительно: скрипту требуется возможность принимать соединения на привилегированные номера TCP-портов – 80 и 443, а также записывать конфигурационные файлы веб-сервера. С этим и связаны очевидные опасения, которые, тем не менее, я опишу.

Если скрипты клиента Let`s Encrypt содержат уязвимости, то уязвимой оказывается и система, в которую был установлен клиент. А то, что скрипты по определению должны принимать внешние соединения – сразу наводит на мысли об удалённом исполнении кода. При этом предполагается, что клиент заведомо используют администраторы, не обладающие высокой квалификацией (квалифицированным он, вообще говоря, не требуется, да и они, обычно, доверяют только собственным рукам). То есть, типичный администратор не будет понимать, что происходит с его сервером во время работы скриптов клиента и, вполне вероятно, не сможет не только предотвратить проблему, но и обнаружить её. Для применения систем защиты информации – это не самый лучший расклад.

К сожалению, похоже, что в обозримом будущем мы можем увидеть сообщения о клиенте Let`s Encrypt примерно следующего содержания: “из-за ошибки в программном коде тысячи TLS-серверов используют уязвимые ключи”, “уязвимость клиента позволяет получить удалённый доступ к секретным ключам”, “ошибка в реализации протокола позволила злоумышленникам выпустить сертификаты для доменов, которые им не принадлежат”. Ну и так далее. Впрочем, нужно понимать, что подобные новости мы и так постоянно читаем, только они касаются других повсеместно используемых библиотек и утилит, так что Let`s Encrypt не принесёт тут ничего принципиально нового в плане угроз и рисков. Разве что ошибки станут сопровождаться автоматическим выпуском SSL-сертификатов.



Comments Off on Let`s Encrypt – публичное бета-тестирование
Навигация по запискам: Раньше »