Год 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 – публичное бета-тестирование

Несколько технических моментов, которые касаются практики использования TLS и интересны в свете обсуждения новостей о готовящемся (якобы) перехвате TLS-соединений в Казнете.

Очевидно, что для прозрачного перехвата TLS достаточно, чтобы перехватывающий узел знал секретный серверный ключ. Но это условие не является необходимым. Перехватывающий узел может не содержать секретного ключа, но успешно проводить перехват. Если вы внимательно посмотрите на протокол установления соединения TLS, то наверняка заметите, что секретный ключ там требуется лишь один раз. Пусть, например, клиент и сервер договариваются о соединении TLS 1.2, использующем AES в качестве шифра и протокол Диффи-Хеллмана на эллиптических кривых (ECDHE) для генерации сеансового ключа. В таком случае секретный ключ сервера требуется только для того, чтобы подписать сообщение Server Key Exchange, содержащее серверные параметры протокола Диффи-Хеллмана. Эту функцию подписывания перехватывающий узел может возложить на легитимный сервер, который, по запросу, подпишет выбранные перехватывающим узлом параметры. Естественно, легитимный сервер должен, таким образом, добровольно принимать участие в перехвате. Эта замечательная и очень полезная технология используется для балансировки нагрузки – в CloudFlare, известном своими передовыми разработками в этой области, она называется Keyless SSL. Кроме того, этот же метод годится для систем обнаружения вторжений (IDS), защиты от атак и множества других полезных приложений.

Предположим, что требуется перехватывать трафик, идущий в сторону сервисов условной компании “Имярек”. Согласие “Имярек” получено. В таком случае, SSL-прокси, расположенный в любой точке сети, действует следующим образом: TCP-сессии, в рамках которых клиенты пытаются установить TLS-соединение с тем или иным сервисом, заводятся прокси на собственный внутренний сервер; этот сервер устанавливает TLS-соединение с клиентом, обращаясь, в нужный момент, за подписью к API “Имярек”; с точки зрения клиента – TLS-соединение выглядит неотличимым от прямого соединения с “Имярек”. Для перехвата не потребовалось иметь секретный ключ, не потребовалось размещать на клиенте специальный сертификат. Однако, потребовалось прямое участие “Имярек” в процессе: эта компания должна предоставить API, позволяющий работать перехватывающим узлам. (В данной схеме есть ещё отдельная задача по трансляции трафика между клиентом и сервером после перехвата. Так, если это HTTPS, то его можно транслировать в HTTP и передавать в открытом виде – но потребуется поддержка HTTP сервисом, что, вообще говоря, неверно. Перехватывающий узел также может установить собственную TLS-сессию с сервером и транслировать клиентский трафик через неё. Но детали – оставим за рамками этой записки.)

Трафик TLS-сессии защищается сеансовым ключом. Если на перехватывающем узле не требуется полное управление установлением соединения, а нужна только возможность доступа к трафику, то такой прокси может просто получать текущий сеансовый ключ (и, строго говоря, криптографический контекст) с TLS-сервера. В TLS даже существует стандартный механизм маркирования сессий при помощи уникального идентификатора, который передаётся в открытом виде. Сценарий: SSL-прокси начинает записывать трафик, обнаружив TLS-соединение; параллельно отправляется запрос в API сервиса, трафик которого требуется прочитать, – запрос содержит уникальный идентификатор сессии (он передаётся при установлении соединения в открытом виде); в ответ сервис присылает сеансовый ключ и начальное состояние сеанса, если оно требуется. В результате проксирующий узел может пассивно просматривать трафик. Секретный серверный ключ от сертификата не потребовался, специальный сертификат – тоже. Но, опять же, необходимо участие провайдера сервиса. Последний, впрочем, во всех случаях сохраняет контроль над секретным серверным ключом, а предоставление API для получения подписей – не является большой технической проблемой. Ключевой момент: так как провайдер сервиса добровольно участвует в работе системы перехвата, оба описанных метода не нарушают никаких регламентов и требований инфраструктуры TLS глобальной Сети.

Если договориться с провайдером сервиса не удаётся, то возможен другой вариант: участие хорошо известного удостоверяющего центра (УЦ). “Хорошо известного” – в том смысле, что признаваемого браузерами (в случае с HTTPS). Схема с выпуском перехватывающих промежуточных сертификатов – тоже хорошо известна, некоторые УЦ на этой схеме даже попадались. SSL-прокси может взаимодействовать с УЦ следующим образом. Прокси перехватывает TLS-соединение в момент установления, после чего отправляет на специальный API УЦ запрос с сетевым именем, к которому обращается клиент. УЦ известен секретный ключ, который прокси использует при перехвате. УЦ в режиме онлайн выпускает “короткоживущий” сертификат (например, валидный в течение суток) для ключа прокси и требуемого сетевого имени. Этот сертификат возвращается в качестве ответа API. Далее SSL-прокси использует его для подмены и, таким образом, выдаёт себя за узел, с которым пытался соединиться клиент. Выпуск сертификата занимает короткое время, при этом секретные ключи, необходимые для выпуска сертификатов, не покидают пределов информационных систем УЦ. При таком перехвате поломается заметное число приложений, использующих TLS, в частности, браузеры, поддерживающие Key Pinning, будут выдавать предупреждение системы безопасности – так как используемый прокси ключ не соответствует серверному.

В описанной выше схеме потребовался выпуск сертификата, потребовалось участие УЦ, зато не требуется согласия провайдера сервиса, соединения в направлении которого перехватываются, также не требуется устанавливать дополнительный сертификат на клиенте – там уже есть нужный сертификат УЦ. Основная проблема: предоставление подобного API (которое легко маскируется под обычный партнёрский интерфейс УЦ) прямо нарушает регламенты и требования, поэтому представляет собой угрозу для бизнеса УЦ. (Занятно, что в сентябре 2015 года УЦ Symantec оказался пойман на выпуске большого числа короткоживущих “тестовых сертификатов” для доменов, администраторы которых сертификатов не заказывали. Возник даже некоторый скандал.)

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

(Напомню, кстати, что я поддерживаю специальный ресурс, детально описывающий технические подробности TLS.)



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

Занятную новость распространяют, например, Roem.ru: “c 1 января 2016 Казахстан будет перехватывать весь HTTPS-трафик с помощью корневого сертификата”. Официального подтверждения, впрочем, пока найти не удалось. Технически, речь идёт об установке на клиентской стороне доверенного корневого сертификата. Это эквивалентно добавлению ещё одного УЦ и, соответственно, в общем случае, позволит прозрачно для пользователя перехватывать TLS-соединения (например, HTTPS), если перехватывающий узел содержит доверенные ключи. Решения такие давно есть, называется это SSL-proxy – подробнее я писал в заметке о перехвате HTTPS.

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

(Да, на всякий случай, добавлю очевидное: подобный тотальный прямой перехват, если его действительно вводят, полностью ломает TLS-инфраструктуру, сложившуюся в Сети – никакого прикладного смысла в ней не остаётся.)



Комментарии (4) »
Навигация по запискам: Раньше »