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

Определение политики безопасности

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

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

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

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

Размеры пакета и заголовка

Минимальный размер пакета SSH равен 28 байтам. Возрастание минимального размера по сравнению с заголовками TCP/IP незначительно для больших пакетов, но очень существенно для небольших, коими являются сессии telnet. Минимальный размер заголовка TCP/IP равен 32 байтам. Таким образом, реально заголовок пакета возрастает с 33 до 61 байта.

Общая доля данных типа telnet в Internet незначительна, поэтому общая нагрузка на трафик небольшая.

Только в одном случае возрастающий размер пакета имеет важное значение – при соединении по медленному модему. Протокол РРР сжимает заголовки TCP/IP, подчеркивая возрастание размера пакета.

Некоторые проблемы могут быть связаны с максимальным размером пакета. Для минимизации задержки на изменение экрана не должно быть больших пакетов в интерактивных сессиях. О максимальном размере пакета договариваются отдельно для каждого канала.

Локализация и поддержка различных наборов символов

В большинстве случаев протоколы SSH непосредственно не выводят текст на терминал пользователя. Тем не менее, существует несколько случаев, в которых данные должны быть выведены на терминал. В этом случае набор символов должен быть указан явно. В большинстве случаев используется кодировка ISO 10646 UTF-8. При этом определяется поле для тега языка.

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

Внутренние имена, используемые для идентификации алгоритмов и протоколов, обычно никогда не показываются пользователям и должны быть в US-ASCII.

Хотя имя пользователя и клиент, и сервер определяют внутренне, оно должно быть показано в логах, отчетах и т.п. Имена должны иметь кодировку ISO 10646 UTF-8, но в некоторых случаях могут требоваться другие кодировки.

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

Способ именования объектов протокола

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

Для имен алгоритмов существует два формата:

1. Имена, которые не содержат символ " @ ", зарезервированы для обозначений IANA. Примерами являются '3des-cbc', 'sha-1', 'hmac-sha1'. Имена данного формата не должны использоваться без регистрации в IANA. Зарегистрированные имена не должны содержать символов " @ " или " .".
2. Можно определить дополнительные алгоритмы, используя имена в формате name@domainname. Часть, следующая за символом @, должна представлять собой полностью определенное доменное Internet-имя лица или организации, определяющих его. Каждый домен управляет своим локальным пространством имен.