Безопасность и аутентификация: SSL vs SASL

Я понимаю, что SSL объединяет алгоритм шифрования (например, AES, DES и т. д.) с помощью метода обмена ключами (например, Diffier-Hellman) для обеспечения безопасного шифрования и идентификации между двумя конечными точками в незащищенной сети (например, в Интернете).

Я понимаю, что SASL-это протокол MD5/Kerberos, который в значительной степени делает то же самое.

Итак, мой вопрос: каковы плюсы / минусы выбора обоих и какие сценарии делают либо больше предпочтительнее? В принципе, я ищу некоторые рекомендации, чтобы следовать при выборе SSL или пойти с SASL вместо этого. Заранее спасибо!

37
encryption kerberos md5 sasl ssl

3 ответов

довольно сложно сравнить SSL/TLS и SASL, потому что SSL / TLS-это протокол связи, тогда как SASL-это фреймворк, интегрированный с другими протоколами. (На самом деле, вы можете использовать оба одновременно в некоторых обстоятельствах.)

кроме того, вы упоминаете Kerberos, который действительно является протоколом аутентификации (который может использоваться с SSL/TLS или SASL или независимо друг от друга). Ваш вопрос, похоже, предполагает, что ли использовать Kerberos одну из основных под-проблем ты должен выбрать первым.

SASL по существу является косвенным уровнем, позволяющим подключаемым системам аутентификации и безопасности данных в существующих протоколах приложений (e.G LDAP, SMTP, Subversion, ...), хотя эти протоколы должны знать об этом расширении (например,SMTP auth). Обеспечивает ли и как он безопасную аутентификацию и шифрование данных, в значительной степени зависит от того, что базовый механизм используется в этой структуре. Вот пример от svnserve документация: "встроенный механизм CRAM-MD5 не поддерживает шифрование, но DIGEST-MD5 делает". Если вы хотите использовать Kerberos с SASL, вам понадобится другой уровень косвенности:GSS-API (который чаще всего используется с Kerberos, но может также учитывать другие механизмы). (Обратите внимание, что GSSAPI в контексте SASL, похоже, подразумевает Kerberos в любом случае, в отличие от его GS2 правопреемником.)

в общая цель SSL / TLS-обеспечить связь (целостность и конфиденциальность) между клиентом и сервером. Клиент всегда должен проверять удостоверение сервера SSL / TLS, и он предоставляет механизмы для сервера, чтобы проверить удостоверение клиента тоже. Что он может сделать, зависит от того, как он настроен. SSL / TLS чаще всего используется с сертификатами X. 509: именно так браузер может проверить идентификатор сервера HTTPS. Серверы также можно настроить для запроса клиента на использование сертификат для идентификации себя (клиент-аутентификация сертификата). Однако, если вы хотите использовать Kerberos, вы можете использовать TLS Kerberos cipher suites. Это гораздо реже встречается, но они реализовано в JSSE.

его реализации обычно предоставляют API, подобные тому, что вы получаете с обычными TCP-соединениями: в Java, после настройки, вы можете более или менее использовать SSLSocket как вы бы использовать обычный Socket. Это не требует определенных осведомленность протоколом поверх сокета, хотя некоторые протоколы имеют явные команды для переключения на SSL / TLS из простого соединения (неявные v. s. Явный SSL / TLS). Он также может обеспечить аутентификацию. В Java по jsse является реализацией SSL/TLS по умолчанию, которая дает вам доступ к SSLSocket (или SSLEngine если вы достаточно смелы).

возможно, вы захотите прочитать "когда использовать Java GSS-API против JSSE", который похож на "SASL vs. SSL / TLS" (хотя он, похоже, не обновлялся некоторое время, так как JSSE тут поддержка наборов шифров Kerberos сейчас, по крайней мере, начиная с Oracle Java 6).

Я признаю, что знаю меньше о SASL, чем о SSL/TLS, но шифрование данных через SASL звучит так, как будто это будет больше работы. Кажется, у него нет определенных функций SSL / TLS, таких как совершенная передняя секретность, предлагаемая EDH cipher suites. Есть пример, который использует SASL с GSSAPI (Kerberos здесь) в учебнике jgss: вам нужно обернуть/развернуть данные явно, что вам не придется делать при использовании SSLSockets.

Я думаю, что ваша главная забота должна состоять в том, чтобы решить, какой механизм аутентификации вы хотите использовать в первую очередь: Kerberos, сертификаты X. 509 или что-то еще. Это будет иметь большее влияние на вашу общую архитектуру, и оба могут использоваться с SASL и SSL/TLS (более того, если вы используете SASL с Ан EXTERNAL механизм, когда поверх соединения SSL/TLS).

  • Kerberos очень централизован. Клиент должен иметь возможность связаться с KDC для проверки подлинности, в дополнение к возможности связаться с сервером приложений. Клиенты также должны быть настроены для использования "КДК". С точки зрения пользователя, они могут использовать пароли.
  • X. 509 более децентрализован. Однако может потребоваться развернуть Центр сертификации (или использовать коммерческий центр) для ваших сертификатов пользователя. Пользователям необходимо будет предоставить сертификаты и закрытые ключи, которые некоторые могут найти слишком сложными.

JAAS входит в него, потому что это общая структура Java для работы с аутентификацией и авторизацией. Это очень тесно связано с понятием менеджеров безопасности. Это дает вам понятие Subject и Principal. Это напрямую не связано с протоколами или связью, а скорее с тем, как вы моделируете аутентификация и авторизация в приложении. (Это дает вам стандартный набор классов для этого.)

(Я бы вообще предложил пройти через справочники по Java это упоминание слов, которые вы ищете: JGSS, SASL,... хотя их не всегда легко читать.)

66

SSL vs SASL

Это правда, что SASL-это не протокол, а слой абстракции. Также верно, что SSL и SASL предоставляют аналогичные функции. Оба они обеспечивают аутентификацию, подписание данных и шифрование.

SSL выполняется на транспортном уровне, и это обычно прозрачный к нижнему протоколу. Например, можно использовать SSL для LDAP или HTTP. Однако в некоторых случаях изменение существующих протоколов необходимо для перехода в защищенный режим. Например, POP3 и IMAP расширены, чтобы иметь команду STARTTLS инициировать использование SSL. С этой точки зрения это похоже на то, что делает SASL.

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

Так, когда мы должны использовать SSL и когда мы должны использовать SASL?

очевидная разница между SSL и SASL заключается в том, что SASL позволяет выбирать различные механизмы для аутентификации клиента, в то время как SSL привязан к аутентификации на основе сертификата. В SASL вы можете использовать GSSAPI, Kerberos, NTLM и т. д.

из-за этой разницы, есть некоторые ситуации, это просто более интуитивно использовать SASL, но не SSL. Например, клиентское приложение использует Kerberos для проверки подлинности конечного пользователя. Ваш сервер должен аутентифицировать клиента. Поскольку клиентское приложение уже имеет учетные данные Kerberos (в терминологии Kerberos-билет), имеет смысл использовать учетные данные Kerberos для проверки подлинности на сервере. Конечно, вы всегда можете настроить SSL, чтобы сделать то же самое. Однако, это означает, что на существующую инфраструктуру Kerberos, необходимо получить сертификат настройки infrasture власти и как-то соотнести сертификат клиента с учетными данными Kerberos. Это выполнимо, но много работы.

кроме того, иногда вам нужно использовать некоторые функции, доступные только в механизме SASL, но не SSL. Например, Kerberos позволяет пересылать билет от клиента на сервер, чтобы сервер мог использовать билет для запроса некоторых ресурсов от имени клиента. Одним из распространенных примеров является наличие сервера приложений и базы данных. Клиентское приложение выполняет проверку подлинности с помощью сервера приложений и сервер приложений должен запросить базу данных от имени клиента, используя учетные данные клиента. SSL не может предоставить эту функцию, но Kerberos поддерживает ее. Итак, в этом случае вы должны выбрать использование SASL.

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

как GSSAPI относится к Kerberos и Для SASL

по этому страница wiki, и GSSAPI и Kerberos поддерживаются mechansim в SASL. GSSAPI-это универсальный программный интерфейс. Идея состоит в том, чтобы позволить application writer использовать один общий API для аутентификации, шифрования и т. д. независимо от того, какой протокол используется под ним. Gssapi реализует Kerberos. Таким образом, вы можете использовать GSSAPI для проверки подлинности Kerberos.

как JAAS относится к SASL

будет честно говоря, я не эксперт по Java. Из того, что я читал, похоже, что JAAS-это просто подключаемая структура аутентификации. Я верю, что идея похожа на GSSAPI. Это обеспечить единый интерфейс программирования независимо от того, какой метод аутентификации используется. В то время как GSSAPI фокусируется на аутентификации и защищенном обмене сообщениями, JAAS фокусируется на аутентификации и авторизации. Я не нахожу никаких доказательств того, что ЯАС также является одним из механизмов SASL. Я считаю, что должен быть какой-то помощник классы из библиотеки Java помогают реализовать пользовательские механизмы SASL. При реализации пользовательского механизма SASL может иметь смысл просто использовать JAAS.

21

SASL-это не протокол, а слой абстракции для некоторого механизма аутентификации. Если вы используете Digest-MD5 или GSS-API в качестве механизма SASL, вы можете запросить SASL для полного шифрования трафика данных. Это, например, то, что я делаю, чтобы поговорить с вашими серверами Active Directory. Вам не понадобится SSL. Каков ваш вариант использования. Пожалуйста, уточните!

2