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

Несколько технических моментов, которые касаются практики использования 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.)

Адрес записки: https://dxdt.ru/2015/12/04/7748/