Как я понял, EAP-TTLS и PEAP имеют одинаковый уровень безопасности при реализации в беспроводных сетях. Оба обеспечивают аутентификацию только на стороне сервера через сертификат.
Недостатком EAP-TTLS может быть неродная поддержка Microsoft Windows, поэтому каждому пользователю приходится устанавливать дополнительное программное обеспечение.
Преимущество EAP-TTLS может заключаться в поддержке менее безопасных механизмов аутентификации (PAP, CHAP, MS-CHAP), но зачем они вам нужны в современной и должным образом защищенной беспроводной системе?
Какого вы мнения? Почему я должен использовать EAP-TTLS вместо PEAP? Допустим, у меня больше всего пользователей Windows, средних пользователей Linux и меньше всего пользователей iOS и OSX.
клиенты iOS не поддержу EAP-TTLS с участием PAP (только MsCHAPv2) если вы не установите профиль вручную (через компьютер).
Клиенты Windows не поддержу EAP-TTLS прямо из коробки (вам потребуется установить такое программное обеспечение, как secure2w), если у них нет беспроводных карт Intel.
Android поддерживают почти все комбинации EAP и PEAP.
Таким образом, настоящая проблема заключается в том, как хранятся ваши пароли.
Если они в:
Active Directory, тогда вы можете использовать EAP-PEAP-MsCHAPv2 (Боксы Windows) и EAP-TTLS-MsCHAPv2 (с клиентами iOS).
Если вы храните пароли на LDAP, ты можешь использовать EAP-TTLS-PAP (Коробки Windows), но вы запутаетесь в iOS.
EAP-TTLS и PEAP использовать TLS (Безопасность транспортного уровня) более EAP(Расширяемый протокол аутентификации). Как ты можешь знать, TLS это более новая версия SSL и работает на основе сертификатов, подписанных доверенным центральным органом (Certification Authority - CA).
Создать TLS туннель, клиент должен подтвердить, что он разговаривает с правильным сервером (в данном случае это сервер RADIUS, используемый для аутентификации пользователей). Для этого он проверяет, предоставил ли сервер действительный сертификат, выданный доверенным центром сертификации.
Проблема в том, что обычно у вас не будет сертификата, выпущенного доверенным центром сертификации, а будет сертификат, выпущенный специальным центром сертификации, созданным специально для этой цели. Операционная система будет жаловаться пользователям на то, что она не знает, что CA и пользователи (в соответствии с вашей ориентацией) с радостью примут это.
Но это создает серьезную угрозу безопасности:
Кто-то может установить мошенническую точку доступа внутри вашего предприятия (в сумке или даже на ноутбуке), настроить ее для взаимодействия со своим собственным сервером RADIUS (работающим на его ноутбуке или на собственной мошеннической точке доступа).
Если ваши клиенты обнаружат, что эта точка доступа имеет более сильный сигнал, чем ваши точки доступа, они попытаются подключиться к ней. Увидит неизвестный CA (пользователи принимают), установит TLS туннель, отправит аутентификационную информацию по этому туннелю, и мошеннический радиус будет регистрировать ее.
Теперь важная часть: если вы используете схему аутентификации в виде обычного текста (PAP например), сервер мошеннического радиуса будет иметь доступ к паролям ваших пользователей.
Вы можете решить эту проблему, используя действительный сертификат, выданный центром сертификации, которому доверяют как iOS, так и Windows (и Android). Или вы можете распространить корневой сертификат ЦС среди своих пользователей и сообщить им об отказе от подключения, когда они видят проблемы с сертификатом (удачи с этим).
PEAPv0, PEAPv1 и TTLS имеют одинаковые свойства безопасности.
PEAP - это оболочка SSL для EAP, несущая EAP. TTLS - это оболочка SSL вокруг TLV диаметра, несущих атрибуты аутентификации RADIUS.
EAP-TTLS-PAP может быть полезен (а не EAP-PEAP или EAP-TTLS), если база данных аутентификации серверной части хранит учетные данные в необратимом формате хэша, таком как bigcrypt, или в любой другой форме, несовместимой с MSCHAP (NT-OWF). в случае невозможности аутентификации с использованием любого из методов на основе CHAP.
Хотя вы также можете эмулировать PAP с помощью EAP-PEAPv1-GTC, это не так широко поддерживается клиентами.
PEAP имеет некоторый дополнительный багаж по сравнению с TTLS в виде головных болей при согласовании версии PEAP и исторической несовместимости в PEAPv1 (например, клиентское волшебство при получении главного ключа из PRF), которые вошли в ранние реализации.
Обычно я вижу, что EAP-TTLS реализован во встроенных клиентах, таких как абонентские модули в беспроводном оборудовании, с PEAP, который больше используется портативными компьютерами и мобильными телефонами.
EAP-TTLS исторически не поддерживался клиентами Windows без установки стороннего программного обеспечения. EAP-TTLS теперь поддерживается начиная с Windows 8.
Некоторые дополнительные мысли:
EAP-TTLS был изобретен поставщиком RADIUS. EAP-PEAPv0 был изобретен Microsoft. EAP-PEAPv1 возник в процессе IETF.
IETF проделала некоторую дополнительную работу над PEAPv2, которая сделала бы систему более безопасной за счет криптографических привязок к внутренним методам аутентификации. Насколько я могу судить, до этого еще далеко.
Как писал пожиратель дисков, основная причина, по которой люди используют TTLS, заключается в том, что вы можете разрешить своему серверу RADIUS видеть пароль в открытом виде, что может быть полезно в зависимости от вашего бэкэнда аутентификации.
Новое соображение, которое может отдать предпочтение PEAP, заключается в том, что SoH AFAICT предоставляется серверу RADIUS только в том случае, если он его запрашивает, и единственный способ запросить его в системах Microsoft - это во время сеанса PEAP. Поэтому, если вы хотите получить агентную оценку из безагентной оценки (поддержка со стороны других поставщиков антивирусных программ, вероятно, будет в будущем), вам понадобится PEAP, однако, если вы хотите обойти однофакторный бэкэнд OAUTH, взяв открытый пароль (потому что черт возьми, крупные IDP, которые не будут предоставлять услуги внутреннего туннеля, заслуживают не меньшего, а их пользователи достаточно невежественны, чтобы ввести его) используют TTLS.
Вы можете поддерживать оба, если ваш серверный модуль RADIUS поддерживает это. Однако некоторые клиенты "автоматически" подключаются (например, Mac OS X> = 10.7 + iOS), и они могут работать неоптимально, если вы поддерживаете более одного типа, поскольку они просто пробуют разные комбинации, пока один из них не сработает, т.е. с меньшими хлопотами, если есть только один способ подключения.
Итак, в основном: поддерживайте только PEAP или PEAP + TTLS, если у вас есть клиенты, которым требуется TTLS.
Вы должны учитывать, какие методы EAP поддерживает клиент изначально, а какие с помощью дополнительного программного обеспечения, и какие методы внутренней аутентификации поддерживает сервер.
Протоколы PEAP и EAP-TTLS предназначены для проверки идентификации сервера, но вы должны убедиться, что клиенты правильно настроены для проверки сертификата.
PEAP и MS-CHAPv2 хорошо поддерживаются клиентами, но если ваш сервер не поддерживает MS-CHAPv2 (потому что вы не храните пароли в открытом виде), вам нужно придумать другое решение. Это основная причина, по которой вы увидите, что люди используют EAP-TTLS и PAP.
Я думаю, что автоматическое подключение выиграет от обоих вариантов, чем больше вариантов, тем меньше хлопот ... например. если автоматическое подключение сначала пытается TTLS-PAP, а затем PEAP-MSCHAP, автоматическое подключение выполняется быстрее с доступным TTLS-PAP. В общем: поддерживайте оба, недостатка не вижу.
Поскольку безопасность MSCHAP нарушена (google для "crack mschap") pap с открытым текстом пароля через ttls имеет тот же уровень безопасности, что и PEAP-MSCHAP.
Я не знаю каких-либо различий в безопасности между EAP-TTLS и PEAP, поэтому в основном все сводится к поддержке, где PEAP является победителем.