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

Протокол SSH

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

Основные понятия

SSH является протоколом для удаленного безопасного входа и других сетевых сервисов безопасности в недостаточно надежно защищенной сети. Рассмотрим архитектуру протокола SSH, а также основные обозначения, используемые при описании этого протокола. Кроме того, обсудим принципы именования объектов системы, принятые в протоколе SSH, что позволяет реализовывать локальные расширения протокола.

SSH состоит из трех компонентов.

1. Протокол транспортного уровня ( SSH-TRANS ) обеспечивает аутентификацию сервера, конфиденциальность и целостность соединения. Также может дополнительно обеспечивать сжатие данных. Протокол транспортного уровня обычно выполняется поверх соединения TCP, но может использоваться и поверх любого другого надежного соединения.
2. Протокол аутентификации пользователя ( SSH-USERAUTH ) аутентифицирует клиента для сервера. Он выполняется поверх протокола транспортного уровня.
3. Протокол соединения ( SSH-CONN ), мультиплексирует несколько логических каналов в один зашифрованный туннель. Протокол выполняется поверх протокола аутентификации пользователя.

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

Протокол соединения создает каналы, которые могут использоваться для различных целей. Существуют стандартные методы установки безопасных сессий интерактивного shell и перенаправления ("туннелирования") произвольных портов TCP/IP и соединений Х11.

Ключи хоста

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

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

Могут использоваться две различные модели:

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

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

В протоколе существует опция, которая позволяет не проверять связывание имя сервера – открытый ключ при первом соединении клиента с сервером. Это обеспечивает возможность взаимодействия без предварительного знания ключа сервера. В этом случае соединение также обеспечивает защиту от пассивного прослушивания; тем не менее, оно уязвимо для активных атак типа встреча посередине. Реализации не должны допускать такие соединения по умолчанию, если они допускают возможность активных атак. Однако, так как инфраструктура открытого ключа еще недостаточно широко распространена, данная опция делает протокол более приемлемым для взаимодействия сторон, обеспечивая более высокий уровень безопасности, чем такие предыдущие решения как telnet или rlogin.

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

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

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

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

Возможности дальнейшего развития SSH

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

Для идентификации алгоритмов, методов, форматов и протоколов расширения были выбраны текстовые имена определенного формата. Имена DNS используются для создания локального пространства имен, в котором могут быть определены экспериментальные или классифицированные расширения без риска конфликта с другими реализациями.

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