tcpcrypt - тотальное шифрование трафика

08.03.2018

Зачем это надо #

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

Конечно, самую важную информацию вы передаете с использованием протокола TLS. Для почтовых программ, интернет-банков, телекоммуникационных служб использование протокола TLS стало нормой. Однако существует куча сайтов, на которые вы ходите в открытом виде и можете прямо или косвенно оставить важную информацию. Социальные сети, блоги, журналы, магазины, сайты по религии и медицине - все это вы, скорее всего, хотите сохранить в тайне как от соседей, так и от Большого Брата (провайдер, спецслужбы, родители… ). Почему не использовать TLS всегда?

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

Архитектура протокола #

Итак, основными причинами, по которым пользователи НЕ используют шифрование трафика являются:

1. пользователю все равно
2. конфигурация сложна, а выгода минимальна
3. создатели сайтов не заботятся об этом
4. шифрование требует ресурсов
5. использование существующих решений прибавляет много новых проблем

Таким образом, для повсеместного использования шифрования необходимо создание нового решения с продуманной и правильной архитектурой для устранения этих причин.

Почему не используют TLS мы уже упоминали, в тоже время существует еще стандартное решение IPsec. На основе IPsec часто строятся VPN - виртуальные частные сети для работы с удаленным офисом. Данный протокол работает на сетевом уровне модели OSI, т.е. на уровне протокола IP. Это создает массу проблем при использовании NAT (трансляции адресов), что при нынешнем дефиците сетевых адресов IPv4 крайне важно. Существуют обходные решения, но подобная настройка IPsec становится не просто сложной, а архи-сложной. Значит, шифрование должно выполняться выше сетевого уровня.

Далее, протокол TLS, а точнее HTTPS - то, чем мы реально часто пользуемся при использовании браузеров, работает на уровне приложений. Это необходимо прежде всего для организации аутентификации. И как раз данная процедура и является самой сложной в настройке, самой требовательной к ресурсам и основные финансовые затраты тоже там.

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

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

Авторы полагают, что применение атаки типа “человек посредине” (активной атаки) не сравнимо по сложности реализации и распространению с применением обычного пассивного снифера. А значит, использование протокола tcpcrypt без аутентификации (по умолчанию) может оградить пользователя от большинства атак, которым он подвергается. При использовании аутентификации совместно с tcpcrypt уровень защиты пользователя становиться сравнимым с протоколом TLS, только появляется выигрыш в скорости и простоте развертывания.

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

Использование криптографии #

Согласно выбранной архитектуре протокол tcpcrypt должен обеспечивать шифрование и контроль целостности трафика внутри протокола TCP. Первым и самым сложным шагом является распределение ключей. Данный этап должен быть органично включен в процесс рукопожатия протокола TCP и использовать его данные и поля.

При этом процесс распределения ключей является трудоемким, т.к. использует алгоритмы криптографии с открытым ключом. Авторы протокола предлагают вариант распределения ключей на основе шифрования с открытым ключом. В этом случае, утверждается, что сам процесс шифрования и расшифрования для такого алгоритма не симметричен по сложности. К примеру для RSA с размером модуля 2048 бит шифрование выполняется быстрее в 100 раз. Таким образом, для разгрузки сервера есть возможность самую трудоемкую часть переложить на клиента. Заметим, что вариант распределения ключей с помощью протокола Диффи-Хелмана также возможен.

Пусть ENC(K,P) - функция, реализующая алгоритм шифрования текста P c помощью открытого ключа K. Рассмотрим процедуру подключения клиента С к серверу S. Пусть КС - открытый ключ клиента, NС - случайное число, которое вырабатывает клиент, NS - случайное число сервера.

Рис 1. Рукопожатие tcpcrypt. Выработка ключей (слева) и кэширование сессии (справа).

Тогда процедуру выработки общего ключа шифрования можно описать следующими шагами:

C -> S : HELLO S -> C : PKCONF, pub-cipher-list, [cookie] C -> S : INIT1, sym-cipher-list, Nc, Kc, [cookie] S -> C : INIT2, sym-cipher, ENC (Kc, Ns)

Параметры pub-cipher-list и sym-cipher-list содержат списки возможных алгоритмов шифрования. Необязательный параметр cookie является так называемым SYN-cookie и призван защищать соединения от ложных TCP пакетов. После выполнения данных шагов клиент и сервер с использованием псевдослучайной функции (в настоящий момент HMAC) вырабатывают общие секреты ss[i] для каждой TCP сессии i:

ss[0] = HMAC (Ns, {Kc, Nc, cipher-lists, sym-cipher}) ss[i] = HMAC (ss[i-1], TAG_NEXT_KEY)

Пусть ISNCi и ISNSi соответствующие начальное значение номера последовательности TCP. Тогда значение мастер ключа для алгоритмов шифрования и MAC получаются по формуле:

mk[i] = HMAC (ss[i], {TAG_KEY,ISNci , ISNsi})

Далее по полученному общему значению мастер ключа генерируются ключи для симметричных алгоритмов шифрования и MAC стандартными способами. Заметим, что данная схема выполняется только при первом подключении клиента. Для последующих подключений используется упрощенная схема с кэшированием значении параметров сессии.

Интеграция с TCP #

Основным преимуществом протокола tcpcrypt считается его полная обратная совместимость с обычным TCP. Это означает, что при невозможности одного из абонентов работать по протоколу tcpcrypt связь устанавливается по протоколу TCP. Более того, данный протокол должен корректно работать с NAT и различными сетевыми устройствами типа фаерволов и маршрутизаторов.

Этап выработки общего ключа в протоколе tcpcrypt выполняется в рамках процедуры рукопожатия протокола TCP. Вложить все шаги протокола tcpcrypt в три шага рукопожатия TCP не получилось, однако, вся процедура довольно органично вписана в стандартный TCP и требует всего одного дополнительного пакета для пересылки.

Согласно спецификациям TCP первые пакеты с опциями SYN/AСK не должны быть большими. Первые два сообщения HELLO и PKCONF удовлетворяют этому требованию, т.к. содержат лишь запрос на шифрование и списки алгоритмов. Далее сообщение INIT1 маленьким уже не сделаешь, поскольку оно содержит открытые параметры ключевого обмена, и его помещают в область данных стека TCP следующего пакета. Сообщение INIT2 следует уже в обратном направлении подобным образом.

В процессе работы используется только одна новая опция “CRYPT”, все остальные “HELLO”, “PKCONF”, “INIT1” и “INIT2” являются подопциями. Если реализация TCP не распознает опцию “CRYPT” взаимодействие продолжается по обычному протоколу TCP. Для обеспечения целостности данных протокол tcpcrypt добавляет к каждому пакету TCP опцию MAC. Пакеты с несовпадающим значением опцией MAC отбрасываются. Поля, которые подпадают под защиту МАС выделены штриховкой на следующем рисунке.

Рис 2. Опции МАС

Выбор данных полей обусловлен тем, что ряд протоколов, в частности NAT, способны менять некоторые поля заголовка.

Вопросы аутентификации

Итак, самым интересным вопросом является обеспечение аутентификации данного протокола, поскольку по умолчанию данной задачи протокол не решает. Для обеспечения аутентификации авторами протокола предлагается использовать следующий параметр (ID сессии):

sid[i] = HMAC (ss[i], TAG_SESSION_ID)

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

Данное значение ID сессии можно использовать для аутентификации абонентов. Авторы протокола предлагают несколько вариантов такой аутентификации, в том числе с использованием пароля и сертификатов. При использование сертификатов сервер посылает следующее сообщение:

S -> C : Ks, Certificate, Sign (Ks-1, sid[i])

Данное сообщение содержит подпись сервера под ID сесcии и удостоверенная своим сертификатом. Обратная аутентификация проходит схожим образом. Для выполнении аутентификации по паролю в самом простом случае предлагается использовать общий секрет и значение ID сессии для генерации с помощью HMAC последовательности, которой затем абоненты обмениваются. Авторы протокола предлагают так же более сложную схему парольной аутентификации, сходной по структуре с алгоритмом распределения ключей Диффи-Хелмана.

Скорость #

На данный момент существют реализации протокола под Windows, Linux, FreeBSD. Для данных реализаций проведены тесты по скорости. Результаты приведены в таблице.

Нельзя не обратить внимание на большое преимущество протокола tcp перед основным конкурентом SSL при отсутствии кеширования.

Критика #

Сначала о преимуществах. Первое и самое главное - это возможность работы без конфигурации, т.е. из коробки. Например, если поддержка tcpcrypt предусмотрена в ядре Linux, то для пользователя останется незамеченным процесс перехода с обычного TCP к шифрованному. По сравнению с TLS и IPsec это большой плюс. Далее преимущество в скорости. Убрав трудоемкие алгоритмы из протокола и оставив, по сути, только симметричные алгоритмы, авторы протокола сумели добиться внушительных результатов по быстродействию. Это важно прежде всего для владельцев загруженных серверов, которым необходимы защищенные соединения.

Теперь о недостатках. Основной и главный недостаток это отсутствие аутентификации по умолчанию. И тогда вопрос звучит так.

ЧТО ЛУЧШЕ: ИСПОЛЬЗОВАТЬ ШИФРОВАНИЕ БЕЗ АУТЕНТИФИКАЦИИ ИЛИ НЕ ИСПОЛЬЗОВАТЬ ШИФРОВАНИЕ СОВСЕМ?

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

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