Безопасное сетевое взаимодействие (часть 2)
Аннотация: Рассматривается протокол TLS/SSL. Описаны протокол Записи и протокол Рукопожатия, определено понятие «состояние соединения». Описаны используемые криптографические операции и PRF. Рассматриваются расширения, которые могут использоваться для добавления функциональностей в TLS.
Протокол TLS/SSL
Введение
Основная функция протокола TLS состоит в обеспечении защиты и целостности данных между двумя взаимодействующими приложениями, одно из которых является клиентом, а другое – сервером.
Протокол TLS (Transport Layer Security) разрабатывался на основе спецификации протокола SSL 3.0 (Secure Socket Layer), опубликованного корпорацией Netscape. Различия между данным протоколом и SSL 3.0 несущественны, но важно заметить, что TLS 1.0 и SSL 3.0 несовместимы, хотя в TLS 1.0 предусмотрен механизм, который позволяет реализациям TLS иметь обратную совместимость с SSL 3.0.
Перечислим задачи протокола TLS в порядке их приоритета:
- Криптографическая безопасность: TLS должен использоваться для установления безопасного соединения между двумя участниками.
- Интероперабельность: независимые разработчики могут создавать приложения, которые будут взаимодействовать по протоколу TLS , что позволит устанавливать безопасные соединения.
- Расширяемость: TLS формирует общий каркас, в который могут быть встроены новые алгоритмы открытого ключа и симметричного шифрования. Это также избавляет от необходимости создавать новый протокол, что сопряжено с опасностью появления новых слабых мест, и предотвращает необходимость полностью реализовывать новую библиотеку безопасности.
- Относительная эффективность: криптографические операции интенсивно используют ЦП, особенно операции с открытым ключом. Для этого вводится понятие сессии, для которой определяются алгоритмы и их параметры. В рамках одной сессии может быть создано несколько соединений (например, ТСР). TLS позволяет кэшировать сессии для уменьшения количества выполняемых действий при установлении соединения. Это снижает нагрузку как на ЦП, так и на трафик.
Протокол состоит из двух уровней. Нижним уровнем, расположенным выше некоторого надежного протокола (а именно, протокола ТСР) является протокол Записи . Протокол Записи обеспечивает безопасность соединения, которая основана на следующих двух свойствах:
- Конфиденциальность соединения. Для защиты данных используется один из алгоритмов симметричного шифрования. Ключ для этого алгоритма создается для каждой сессии и основан на секрете, о котором договариваются в протоколе Рукопожатия . Протокол Записи также может использоваться без шифрования.
- Целостность соединения. Обеспечивается проверка целостности сообщения с помощью МАС с ключом. Для вычисления МАС используются безопасные хэш-функции SHA -1 и MD5. Протокол Записи может выполняться без вычисления МАС, но обычно функционирует в этом режиме.
Протокол Записи используется для инкапсуляции различных протоколов более высокого уровня. Одним из протоколов более высокого уровня является протокол Рукопожатия , который использует протокол Записи в качестве транспорта для ведения переговоров о параметрах безопасности. Протокол Рукопожатия позволяет серверу и клиенту аутентифицировать друг друга и договориться об алгоритмах шифрования и криптографических ключах до того, как прикладной протокол, выполняющийся на том же уровне, начнет передавать или принимать первые байты данных.
Протокол Рукопожатия обеспечивает безопасность соединения, которая основана на следующих свойствах:
- Участники аутентифицированы с использованием криптографии с открытым ключом (т.е. с использованием алгоритмов RSA, DSS и т.д.). Эта аутентификация может быть необязательной, но обычно требуется по крайней мере для сервера.
- Переговоры о разделяемом секрете безопасны, т.е. этот общий секрет невозможно подсмотреть.
- Переговоры о разделяемом секрете надежны, если выполнена аутентификация хотя бы одной из сторон. В таком случае атакующий, расположенный в середине соединения, не может модифицировать передаваемый секрет незаметно для участников соединения.
Одно из преимуществ TLS состоит в том, что он независим от прикладного протокола. Протоколы более высокого уровня могут прозрачно располагаться выше протокола TLS .
Безопасное сетевое взаимодействие (часть 3)
Аннотация: Рассматривается протокол удаленного безопасного входа SSH. Определяется понятие ключа хоста, описан алгоритм транспортного уровня, способ аутентификации сервера и вычисление разделяемого секрета. Описаны методы аутентификации пользователя и механизм канала, обеспечивающий интерактивные входные сессии, удаленное выполнение команд, перенаправление ТСР/IP-соединений, перенаправление Х11-соединений.
Протокол SSH
Архитектура протокола SSH
Основные понятия
SSH является протоколом для удаленного безопасного входа и других сетевых сервисов безопасности в недостаточно надежно защищенной сети. Рассмотрим архитектуру протокола SSH , а также основные обозначения, используемые при описании этого протокола. Кроме того, обсудим принципы именования объектов системы, принятые в протоколе SSH , что позволяет реализовывать локальные расширения протокола.
SSH состоит из трех компонентов.
- Протокол транспортного уровня ( SSH-TRANS ) обеспечивает аутентификацию сервера, конфиденциальность и целостность соединения. Также может дополнительно обеспечивать сжатие данных. Протокол транспортного уровня обычно выполняется поверх соединения TCP, но может использоваться и поверх любого другого надежного соединения.
- Протокол аутентификации пользователя ( SSH-USERAUTH ) аутентифицирует клиента для сервера. Он выполняется поверх протокола транспортного уровня.
- Протокол соединения ( SSH-CONN ), мультиплексирует несколько логических каналов в один зашифрованный туннель. Протокол выполняется поверх протокола аутентификации пользователя.
Клиент посылает запрос на сервис всякий раз, когда устанавливается безопасное соединение на транспортном уровне. Второй запрос сервиса посылается после выполнения аутентификации пользователя.
Протокол соединения создает каналы, которые могут использоваться для различных целей. Существуют стандартные методы установки безопасных сессий интерактивного shell и перенаправления («туннелирования») произвольных портов TCP/IP и соединений Х11.
Ключи хоста
Каждый сервер должен иметь ключ хоста . Серверы могут иметь несколько ключей хоста , используемых различными алгоритмами. Несколько серверов могут разделять один ключ хоста . Каждый сервер должен иметь, по крайней мере, один ключ для каждого обязательного алгоритма открытого ключа. В настоящее время требуется поддерживать алгоритм DSS.
С помощью ключа сервера при обмене ключа можно проверить, действительно ли клиент общается с нужным сервером. Для того, чтобы это было возможно, клиент должен предварительно знать об открытом ключе сервера.
Могут использоваться две различные модели:
- Клиент имеет локальную базу данных, связывающую каждое имя сервера с соответствующим открытым ключом. Этот метод не требует централизованной административной инфраструктуры и трехсторонней координации. В то же время, такую базу данных тяжело поддерживать при большом количестве клиентов и серверов, с которыми они должны взаимодействовать.
- Взаимосвязь имя сервера – ключ проверяется некоторым доверенным сертификационным органом – СА. Клиент знает только ключ корневого CA и может проверить достоверность всех ключей серверов, сертифицированных этими СА.
Второй способ легче с точки зрения поддержки, так как в идеале только единственный ключ корневого СА необходимо хранить у клиента. С другой стороны, каждый хост должен быть соответствующим образом сертифицирован центральным органом перед тем, как можно будет установить безопасное соединение.
В протоколе существует опция, которая позволяет не проверять связывание имя сервера – открытый ключ при первом соединении клиента с сервером. Это обеспечивает возможность взаимодействия без предварительного знания ключа сервера. В этом случае соединение также обеспечивает защиту от пассивного прослушивания; тем не менее, оно уязвимо для активных атак типа встреча посередине. Реализации не должны допускать такие соединения по умолчанию, если они допускают возможность активных атак . Однако, так как инфраструктура открытого ключа еще недостаточно широко распространена, данная опция делает протокол более приемлемым для взаимодействия сторон, обеспечивая более высокий уровень безопасности, чем такие предыдущие решения как telnet или rlogin.
Реализации протокола должны пытаться обеспечивать проверку ключей сервера. Например, можно попробовать принимать ключ сервера без проверки только в первый раз, сохранять ключ в локальной базе данных и сравнивать этот ключ при всех последующих соединениях с данным сервером.
Реализации могут предоставлять дополнительные способы проверки корректности ключей сервера, например, вычислять хэш открытого ключа, который можно легко проверить с помощью телефона или других внешних коммуникационных каналов.
Все реализации должны обеспечить опцию, не позволяющую принимать ключи сервера, которые невозможно проверить.
Предполагается, что простота использования является важным критерием при работе с тем или иным прикладным продуктом, повышающим безопасность сетевого взаимодействия. Таким образом, создавая опцию, позволяющую не проверять ключ сервера, разработчики считали, что это повысит общую безопасность Internet, даже если несколько снизит безопасность протокола в тех конфигурациях, где допускается такая опция.
Возможности дальнейшего развития SSH
Разработчики надеются, что протокол будет развиваться, и некоторые организации захотят использовать собственные методы шифрования, аутентификации или обмена ключей. Централизованная регистрация всех расширений затруднена, особенно для обеспечения экспериментальных или классифицированных методов. С другой стороны, отсутствие централизованной регистрации приводит к конфликтам в методах идентификации, затрудняя интероперабельность.
Для идентификации алгоритмов, методов, форматов и протоколов расширения были выбраны текстовые имена определенного формата. Имена DNS используются для создания локального пространства имен, в котором могут быть определены экспериментальные или классифицированные расширения без риска конфликта с другими реализациями.
Одна из целей разработки состоит в том, чтобы, с одной стороны, максимально упростить базовый протокол, а с другой стороны, иметь возможность поддерживать несколько алгоритмов. Тем не менее, все реализации должны поддерживать минимальный набор алгоритмов для обеспечения интероперабельности. Это не означает, что политика безопасности на всех серверах должна допускать возможность использования всех алгоритмов. Обязательные алгоритмы, которые должны поддерживаться, описаны в соответствующих документах протокола.