Плохо слышно

На прошлой неделе произошло несколько связанных между собой событий, важных для специалистов по информационной безопасности, но почти незамеченных широкой публикой. Во-первых, ушла на окончательное утверждение в статусе стандарта спецификация протокола TLS 1.3. Во-вторых, была выпущена версия криптобиблиотеки OpenSSL, в которой протокол TLS 1.3 поддерживается по умолчанию. Всё это даёт надежду, что уже к лету мы увидим новую версию протокола в сети. Подробный разбор изменений и улучшений безопасности в новой версии мы оставляем для отдельной большой статьи, а пока что расскажем о нескольких эпизодах разработки спецификации, которые в результате в неё не попали, но вызвали общественный резонанс при обсуждении.

Все эти эпизоды сосредоточены вокруг одного фундаментального изменения в протоколе. В предыдущих версиях TLS поддерживались две основные схемы выработки общих ключей при шифровании. Если излагать упрощённо, то первая — RSA — предлагала выработать общий ключ на стороне клиента и зашифровать его так, чтобы расшифровать его мог только сервер. Вторая же требовала согласование ключей по так называемой схеме Диффи-Хеллмана. Отличие с точки зрения безопасности было принципиальным, особенно ярко проявилось оно после публикации документов Сноудена. В первом случае, если кто-то записал весь трафик, а потом добыл секретный ключ сервера (например, из резервной копии), то он может расшифровать записанное. Второй вариант такого не допускает, и поэтому говорят, что ключевой обмен по схеме Диффи-Хеллмана соответствует требованиям Perfect Forward Secrecy (PFS – приблизительно можно перевести как “устойчивость к атакам из будущего”).

Вариант с ключевым обменом по RSA был исключён из спецификации TLS 1.3 на ранней стадии. Но на митинге IETF осенью 2016 года представители индустрии вышли с предложением вернуть этот вариант. Объяснили они это предложение тем, что в реальных датацентрах необходимо анализировать трафик «на лету». Это нужно для удобства отладки в случае возникновения проблем в пределах контролируемого участка. Шифронаборы с PFS этого не позволяют. Тогда идея была отклонена, но задача, которую было необходимо решать, осталась. Одной из причин отклонения была, в том числе, оптимистическая оценка срока, оставшегося до выхода в свет финальной спецификации.

Прошло примерно полгода, спецификация так и не финализировалась, и на летнем митинге IETF 2017 года состоялась большая дискуссия на ту же тему — как обеспечить возможность анализа трафика в реальном времени в датацентре. На этот раз предложение почти не требовало серьёзных изменений. Вместо того, чтобы каждый раз при установлении соединения генерировать уникальные параметры, предлагалось всего лишь использовать одни и те же параметры в течение некоторого времени (это опять упрощённое изложение, желающие могут почитать оригинальный документ). Это решает задачу быстрого анализа трафика в датацентре, но, как справедливо указали критики в более обширном, но менее структурированном документе, подрывает идеологию, которая легла в основу спецификации новой версии протокола. Одна из серьёзных претензий к предложению — то, что снижается защита пользователей при повторном использовании параметров. Впрочем, аудитория разделилась в соотношении 50 на 50. Это не удивительно: в дискуссии участвовали не только академические специалисты, но и практикующие работники тех самых датацентров, в которых необходимо анализировать трафик. Надо отметить, что этот вариант изменения может быть реализован так, что большинство пользователей его не заметит — и это само по себе является проблемой. Но, так или иначе, документ не обновлялся с лета 2017 года.

В дискуссии на летнем IETF 2017 несколько человек предложили разработать спецификацию безопасного протокола для трех участников, где у третьего (по сути виртуального) участника была бы возможность анализировать трафик, но не вмешиваться в него. И перед осенним IETF такая попытка была предпринята. При этом для допуска третьей стороны в коммуникацию предлагалось использовать явно указанное расширение протокола TLS. У этого решения были явные преимущества перед работой с фиксированными параметрами — клиентское ПО в таком случае может предупредить пользователя о наличии третьего участника в канале, хотя непонятно, остаётся ли у пользователя содержательный выбор в таком случае. Но, к сожалению, анализ показал, что возможности третьей стороны в предложенной схеме не исчерпываются пассивным прослушиванием, и она сможет модифицировать трафик. Поэтому такой вариант был встречен без особого воодушевления.

Но проблема, тем не менее, остаётся, и специалисты пытаются её решить не в ущерб общей безопасности. Одновременно представленной спецификацией протокола “на троих” с аргументированным предложением выступила Катлин Мориарти (Kathleen Moriarty), координирующая в IETF работу в области информационной безопасности. Она предложила использовать внутри датацентра не протокол TLS, а протокол IPSec, защищающий трафик на более низком уровне. Это на первый взгляд позволяет и не ослаблять защиту трафика вне датацентров, и не усложнять спецификацию, и своевременно анализировать трафик при необходимости. Но это предложение, безусловно, потребует тщательного анализа и, скорее всего, существенной доработки существующих систем.

Мы не знаем, сколько времени пройдёт до окончательного доминирования протокола TLS 1.3 в сети — только в начале этого года TLS 1.2, специфицированный в 2008-м году, обогнал по доле поддержки TLS 1.0, специфицированный в 1999-м. Но вопросы о границах применимости уже возникли, и можно надеяться, что ответы на них будут даны своевременно.


Автор:  Дмитрий Белявский (ТЦИ)

Возврат к списку