Безопасное сетевое взаимодействие (часть 3)

Протокол транспортного уровня

Введение

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

Аутентификация пользователя данным протоколом не выполняется. Для этого определен специальный протокол, который расположен выше данного протокола.

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

Установление соединения

SSH работает поверх любого 8-битного надежного транспорта. Транспорт, расположенный ниже, должен защищать от ошибок передачи, чтобы при возникновении ошибки SSH -соединение прерывалось. Как обычно, соединение инициирует клиент.

Обмен версией протокола

Когда соединение уровня ТСР установлено, обе стороны должны послать информационную строку в форме SSH-protoversion-softwareversion comments.

Рассмотрим версию протокола 2.0.

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

Совместимость со старыми версиями SSH

При использовании протокола важно поддерживать совместимость с существующими SSH -клиентами и серверами, использующими более старую версию протокола. Поддерживается совместимость с версиями SSH 1.х.

Старый клиент, новый сервер

Реализации сервера могут поддерживать конфигурационный флаг совместимости, который устанавливает совместимость со старыми версиями. Когда флаг установлен, сервер должен идентифицировать свой протокол версии как 1.99. Клиенты, использующие протокол 2.0, должны идентифицировать его как 2.0.

В режиме совместимости сервер не должен посылать любые данные после своей строки идентификации до тех пор, пока не получит строку идентификации от клиента. После этого сервер может определить, использует ли клиент старый протокол, и в этом случае сам должен использовать старый протокол.

Когда нет необходимости в совместимости со старыми клиентами, сервер может послать свои инициализационные данные обмена ключа непосредственно после строки идентификации.

Новый клиент, старый сервер

Новый клиент может немедленно послать дополнительные данные после своей строки идентификации, т.е. перед получением идентификации сервера. Поэтому старый протокол может уже быть искажен, когда клиент узнает, что сервер старый. В этом случае клиент должен закрыть соединение с сервером и установить соединение, используя старый протокол.

Протокол бинарного пакета

Требование кратности общей длины 8 байтам или размеру блока шифратора, в зависимости от того, что больше, должно выполняться, даже если используется потоковый шифратор. Поле длины пакета также зашифровано.

Максимальная длина пакета

Все реализации должны иметь возможность обрабатывать пакеты с длиной некомпрессированного содержимого 32768 байт или меньше и общий размер пакета 35000 байт или меньше (включая длину, длину добавления, содержимое, добавление и МАС). Реализации должны поддерживать более длинные пакеты, если это необходимо, например, если требуется послать очень большую цепочку сертификатов. Такие пакеты могут быть посланы, если строка версии указывает, что другой участник может обработать их. Тем не менее, реализации должны проверять, приемлема ли длина пакета для принимающей стороны, во избежание отказа в обслуживании или атаки с переполнением буфера.

Компрессия

Если договариваются о компрессии, то поле содержимого и только оно будет сжато с использованием выбранного алгоритма. Поле длины и МАС будут вычислены, исходя из сжатого содержимого.

Компрессия должна быть независимой для каждого направления, и реализации должны позволять независимо изменять алгоритм для каждого направления.

В настоящий момент требуется, чтобы реализации поддерживали нулевую компрессию и метод компрессии zlib.

Шифрование

Об алгоритме шифрования и ключе договариваются во время обмена ключа. Когда шифрование присутствует, длина пакета, длина добавления, содержимое и поля добавления каждого пакета должны шифроваться данным алгоритмом.

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

Алгоритмы шифрования для каждого направления должны выполняться независимо друг от друга, и реализации должны позволять независимое изменение алгоритма для каждого направления (если локальная политика позволяет использование нескольких алгоритмов).

Целостность данных

Целостность данных обеспечивается включением в каждый пакет аутентификационного кода сообщения (МАС), который вычисляется для ключа, последовательного номера пакета и содержимого пакета.

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

mac = MAC (key, sequence_numbеr || 
           unencrypted_packet)

где unencrypted_packet есть весь пакет без МАС (поля длины, содержимого и присоединения) и sequence_number есть полный последовательный номер пакета, представленный как uint32. Последовательный номер первого пакета равен нулю и возрастает для каждого пакета (независимо от того, используется шифрование и МАС или нет). Он никогда не обнуляется, даже если о ключах или алгоритмах договариваются заново. Он возвращается в ноль после 2³² пакетов. Сам последовательный номер пакета не включается в пакет, посылаемый по сети.

Алгоритмы МАС для каждого направления должны выбираться независимо, и реализации должны позволять независимо изменять алгоритм для обоих направлений.

Байты МАС, полученные из алгоритма МАС, должны передаваться без шифрования как последняя часть пакета. Число байтов МАС зависит от выбранного алгоритма.

Методы обмена ключа

Метод обмена ключа определяет создание одноразовых ключей сессии для шифрования и вычисления МАС и определяет также метод аутентификации сервера.

В настоящей версии определен только один метод обмена ключей: diffie-hellman-groupl-shal.

Будем рассматривать именно этот метод.

Алгоритмы открытого ключа

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

Существует несколько аспектов, которые определяют тип открытого ключа:

1. Формат ключа: как ключ шифрует и как представлены сертификаты. Некоторые ключи в данном протоколе могут содержать не только собственно ключ, но и сертификаты.
2. Алгоритмы подписи и/или шифрования. Некоторые типы ключей не имеют возможности одновременно поддерживать и подпись, и шифрование. Использование ключа может также определяться ограничениями политики, например, требованием наличия сертификатов. В данном случае для различных альтернативных политик должны быть определены различные типы ключа.
3. Представление подписи и/или зашифрованных данных. Должно быть специфицировано добавление, упорядочивание байтов, форматы данных и, быть может, дополнительные характеристики.