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

Проект 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-сертификатов.

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

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

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

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

В OpenSSL теперь будет ГОСТ (2012) для TLS:

“Специалисты Технического центра Интернет (ТЦИ) достигли договоренностей о включении поддержки российских криптографических алгоритмов цифровой электронной подписи и хеширования 2012 года ГОСТ Р 34.10-2012 и ГОСТ Р 34-11.2012.”

Силами Дмитрия Белявского. Замечательно. (Соответствующий commit в Git OpenSSL.)

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

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

Опытный пользователь знает о почтовом сервере. И догадывается, что его письмо может прочитать администрация сервера. Однако в администрации он уверен (что читать она не станет) и поэтому полагает переписку секретной, смело доверяя ей весьма скользкие моменты.

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

Дело в том, что пока упомянутый специалист утверждает, что почта нынче ходит между продвинутыми серверами в зашифрованном виде, через TLS и прочие заклинания, настоящие техномаги (80 lvl) “кастуют” подмену DNS и заменяют интересующие их почтовые серверы на свои прокси. Эти прокси отменяют TLS (почтовые протоколы позволяют) и – хлоп! – опять читают “секретную” переписку пользователя, что грозит последнему проблемами, хоть он этого и не понимает.

Вывод и мораль: не используйте математических методов, если вы не понимаете их сути (из известного анекдота про математиков и физиков). Да. Лучше уж подсуньте записку под дверь.

Коодинационный центр – это администратор доменных зон .RU и .РФ. Сегодня объявили о назначении нового директора:

12 октября 2015 года Координационный центр провел пресс-брифинг, на котором был представлен новый директор КЦ Андрей Воробьев, возглавлявший ранее пресс-службу ИРИ, а до этого занимавший должность директора по связям с госорганами крупнейшего российского регистратора Ru-Center. Также на пресс-брифинге был объявлен обновленный состав совета КЦ.

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

Хорошо известна следующая атака: злоумышленники, используя подлог документов, перевыпускают SIM-карту на номер атакуемого пользователя. Это делается через оператора связи. Перехватив таким образом телефонный номер можно захватить и привязанные к нему сервисы, так как появляется возможность принимать SMS и звонки. Часто телефонный номер используется для получения в SMS кода, позволяющего сбросить пароль от пользовательского аккаунта. Этот механизм приготовлен на случай, если пользователь пароль забыл. Интересно, что и механизм замены (перевыпуска) SIM-карты у оператора – служит той же цели: позволить абоненту получить доступ к выделенному ему номеру, если абонент потерял SIM-карту (читай – забыл пароль, хотя SIM-карта – собственность оператора, о чём, кстати, многие равно так же забывают).

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

Доменное имя onion, соответствующее зоне .onion, которая используется внутри TOR для адресации скрытых сервисов, включили в реестр специальных доменов IANA. Зона .onion – это особый домен, доступный только при использовании сети анонимизации TOR. Имена .onion являются криптографическими индексами, связанными с ключами, которые аутентифицируют сервис. То есть, адрес .onion также решает задачу обеспечения “подлинности” ресурса (условно, потому что сеть анонимная). Теперь, после того как домен включили в реестр, можно ожидать выпуска хорошо известными удостоверяющими центрами SSL-сертификатов для этой зоны. Через TOR официально работают и некоторые “обычные” популярные сервисы, например, Facebook.

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

Когда в 2010 году технологию DNSSEC внедрили в корневой зоне DNS – не подумали об алгоритме ротации (замены) корневого ключа. В процессе генерирования безопасного файла зоны участвуют два ключа: KSK и ZSK – последний подписывает записи в зоне, а первый, KSK, это и есть корневой ключ, он удостоверяет ZSK. Соответственно, вся валидация делается от корневого KSK (в зонах, которые находятся уровнем ниже, тоже есть свои KSK, но глобальный, корневой, порождает всю цепочку). Всякий валидирующий DNS-резолвер, если он работает с глобальной DNSSEC от IANA, должен содержать копию открытого ключа корневого KSK, это необходимо для проверки подписей из безопасных зон. В общем, корневой KSK – самый важный элемент инфраструктуры DNSSEC, и технология была запущена без алгоритма регулярной замены этого ключа (хотя про интервал замены “раз в пять лет” речь шла). Бывает.

Сейчас истекли пять лет с момента публикации подписанной корневой зоны DNS. KSK пора бы обновить. Это ключ RSA, имеющий длину 2048 бит. Маловероятно, что кто-то успел его факторизовать за пять лет, но есть же и криптографические традиции. Поэтому ICANN ведёт разработку алгоритма ротации корневого KSK, сейчас предварительный документ с рекомендациями проходит стадию публичного обсуждения.

Рекомендовано сохранить используемую криптосистему (RSA) и разрядность ключа (2048 бит), а дата ротации пока никакими рекомендациями не обозначена. Учитывая, что сейчас идёт процесс по “передачи IANA-функции”, всякие решения по точным алгоритмам и датам – могут только затягиваться (в документе по ссылке про изменение политик IANA, конечно, упомянуто).

Вообще, DNSSEC не слишком широко поддерживается – подписанных зон чрезвычайно мало. Не велико и число операторов валидирующих резолверов. Среди них, наверное, самый влиятельный по объёму запросов – Google, который предоставляет сервис Public DNS, поддерживающий DNSSEC. В теории, впрочем, при неудачной замене корневого KSK все валидирующие резолверы через некоторое время сломаются, потому что любая безопасная зона подписана от корня DNS, а подписи в корне перестанут валидироваться. На практике, новый KSK, с проверкой, можно раздать по крупным операторам вручную, а мелкие – починятся после того, как обнаружат сбой. (Несмотря на то, что есть RFC 5011, надеяться на массовую успешную автоматическую замену ключа было бы очень наивно – это уже не в традициях системного администрирования.)

Интересно, что если замена ключа наложится на замену договора с IANA, то процесс затянется ещё на несколько лет. Вообще, в рекомендациях упомянут 2030 год, как год, до которого можно смело использовать 2048-битные ключи RSA, полагая их стойкими (естественно, с оговоркой про “прорывные достижения”). То есть, время для ротации KSK, похоже, ещё есть.

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

Описание я планирую дополнять, потому что, несмотря на объём, охвачены ещё не все аспекты, которые хотелось бы рассмотреть. Сейчас в деталях рассмотрены такие ключевые моменты, как установление соединения (Handshake) и логика построения обмена сообщениями – это основа основ TLS. В ближайших планах: раздел, разбирающий современные шифры (в различных режимах работы), пояснения про использование криптографии на эллиптических кривых. Вероятно, будут исходники на С, поясняющие некоторые моменты реализаций. Конечно, нужен структурный путеводитель по RFC, имеющим отношение к TLS (их великое множество). Для того, чтобы получился полноценный тематический сайт я выделил проекту отдельный адрес: https://tls.dxdt.ru/. (Правда, пока там многое нужно оформить.)

Если есть какие-то поправки, уточнения, пожелания по новым темам (про что написать подробнее) – сообщайте, пожалуйста, либо мне почтой, либо в комментарии к этой записке.

Сам текст:

Ключи, шифры, сообщения: как работает TLS

В управлении современным Интернетом важнейшую роль играет IANA-функция – то есть, полномочия по распределению имён и номеров, по распределению адресных ресурсов. Например, именно IANA управляет корневой зоной DNS (хотя техническую часть – раздачу экземпляра зоны – реализует компания VeriSign). IANA распределяет блоки IP-адресов, или, скажем, утверждает перечни шифронаборов, используемых в TLS. Сейчас данный рычаг управления находится в руках ICANN, которой он был делегирован минторгом США. Примерно два года назад ICANN запустила (ну или возглавила) процесс по переводу IANA-функции под “контроль интернет-сообщества”. Публичное обсуждение началось весной 2014 года. В планах было осуществить такой перевод уже в этом, в 2015, или в следующем году. Понятно, конечно, что даже если осуществить такой перевод вообще реально, то нереально успеть в столь сжатые сроки.

В результате минторг США теперь планирует продлить имеющийся контракт на выполнение IANA-функции с ICANN до сентября 2016 года, а потом – ещё на три года. Это означает, что никакой “передачи управления Интернетом”, как ожидалось, в ближайшие лет пять не случится.