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

Ответ 1

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

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

SASL - это, по сути, слой косвенности, позволяющий подключать системы аутентификации и защиту данных в существующих протоколах приложений (например, 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. Это гораздо реже, но они реализованы в JSSE.

Его реализации обычно предоставляют API-интерфейсы, аналогичные тем, что вы получаете с простыми TCP-соединениями: в Java, после настройки, вы можете более или менее использовать SSLSocket, поскольку вы использовали бы обычный Socket. Это не требует особой осведомленности по протоколу поверх сокета, хотя некоторые протоколы имеют явные команды для переключения на SSL/TLS из простого соединения (Неявный vs Явный 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, таких как Perfect Forward Secrecy, предлагаемые наборами шифрования EDH. Существует пример который использует SASL с GSSAPI (здесь Kerberos здесь) в учебнике JGSS: вам нужно обернуть/развернуть данные явно, что вы бы 't нужно делать при использовании SSLSocket s.

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

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

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

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

Ответ 2

SSL против 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 вам необходимо настроить инфраструктуру центра сертификации и каким-то образом сопоставить сертификат клиента с учетными данными Kerberos. Это выполнимо, но много работы.

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

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

Как GSSAPI относится к Kerberos и SASL

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

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

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

Ответ 3

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