Как я понял, EAP-TTLS и PEAP имеют одинаковый уровень безопасности при реализации в беспроводных сетях. Оба обеспечивают аутентификацию на стороне сервера только через сертификат.

Недостатком EAP-TTLS может быть не встроенная поддержка в Microsoft Windows, поэтому каждый пользователь должен установить дополнительное программное обеспечение.

Преимущество EAP-TTLS может заключаться в поддержке менее безопасных механизмов аутентификации (PAP, CHAP, MS-CHAP), но зачем вам они нужны в современной и правильно защищенной беспроводной системе?

Что вы думаете? Почему я должен реализовать EAP-TTLS вместо PEAP? Допустим, у меня есть большинство пользователей Windows, средних пользователей Linux и наименьшего количества пользователей iOS, OSX.

Вы можете поддерживать оба, если ваш сервер RADIUS поддерживает это. Однако некоторые клиенты «автоматически» подключаются (например, Mac OS X> = 10.7 + iOS), и они могут работать неоптимально, если вы поддерживаете более одного типа, так как они просто пробуют разные комбинации, пока один из них не будет работать, т.е. с меньшими хлопотами, если есть только один способ подключения.

Итак, в основном: поддержка только PEAP или PEAP + TTLS, если у вас есть клиенты, которым требуется TTLS.

Клиентские ограничения

• клиенты 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и работает на основе сертификатов, подписанных доверенным центральным органом (Центр сертификации - CA).

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

Проблема в том, что обычно у вас не будет сертификата, выданного доверенным центром сертификации, а сертификата, выданного специальным центром сертификации, который вы создали именно для этой цели. Операционная система будет жаловаться пользователям, что она не знает, что CA и пользователи (как вы ориентируетесь) с радостью примут это.

Но это создает серьезную угрозу безопасности:

Кто-то может настроить мошенническую точку доступа внутри вашего предприятия (в сумке или даже на ноутбуке), настроить его для связи со своим собственным сервером радиуса действия (работает на своем ноутбуке или на собственной мошеннической точке доступа).

Если ваши клиенты считают, что этот AP имеет более сильный сигнал, чем ваши точки доступа, они попытаются подключиться к нему. Увидит неизвестный центр сертификации (пользователи примут), установит TLSтуннель, отправит аутентификационную информацию по этому туннелю, а радиус мошенника запишет его.

Теперь важная часть: если вы используете схему аутентификации в виде простого текста ( PAPнапример), сервер мошеннического радиуса будет иметь доступ к паролям ваших пользователей.

Вы можете решить эту проблему, используя действующий сертификат, выданный центром сертификации как для iOS, так и для Windows (и Android). Или вы можете разослать корневой сертификат CA своим пользователям и сообщить им об отказе от подключения, когда они увидят проблемы с сертификатом (удачи вам в этом).

PEAPv0, PEAPv1 и TTLS имеют одинаковые свойства безопасности.

PEAP - это оболочка SSL вокруг EAP, несущая EAP. TTLS - это оболочка SSL с TLV диаметра, имеющая атрибуты аутентификации RADIUS.

EAP-TTLS-PAP может быть полезен по сравнению с EAP-PEAP, если учетные данные базы данных внутренней аутентификации хранятся в необратимом хеш-формате, таком как 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, заключается в том, что вы можете позволить вашему серверу радиуса таким образом видеть пароль в виде открытого текста, что может быть полезно в зависимости от вашей серверной аутентификации.

Более новым соображением, которое может быть в пользу PEAP, является то, что SoH является AFAICT, представляемым серверу RADIUS, только если он запрашивает его, и единственный способ запросить его в системах Microsoft - во время сеанса PEAP. Поэтому, если вы хотите получить оценку, подобную агенту, из оценки без агента (возможно, будет оказана поддержка со стороны большего числа производителей AV-продуктов), вам понадобится PEAP, однако, если вы хотите обойти 1-факторный сервер OAUTH, взяв открытый пароль (потому что черт, большие ВПЛ, которые не будут предоставлять услуги внутреннего туннеля, заслуживают не меньшего, и их пользователи не имеют ни малейшего понятия, чтобы их набрать) используют TTLS.

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

PEAP и EAP-TTLS предназначены для проверки идентификатора сервера, но вы должны убедиться, что клиенты правильно настроены для проверки сертификата.

PEAP и MS-CHAPv2 хорошо поддерживаются клиентами, но если ваш сервер не поддерживает MS-CHAPv2 (потому что вы не храните пароли в виде открытого текста), вам придется придумать другое решение. Это основная причина, по которой вы увидите, что люди используют EAP-TTLS и PAP.

Я думаю, что автоматическое подключение выиграет от обоих вариантов, чем больше вариантов, тем меньше хлопот ... например. если при автоматическом подключении сначала выполняется TTLS-PAP, а затем PEAP-MSCHAP, автоматическое подключение выполняется быстрее при наличии TTLS-PAP. Так что в основном: поддерживать оба, я не вижу недостатка.

Поскольку безопасность MSCHAP нарушена (Google для «взломать mschap»), pap с паролем открытого текста через ttls имеет тот же уровень безопасности, что и PEAP-MSCHAP.

Я не знаю каких-либо различий в безопасности между EAP-TTLS и PEAP, поэтому все сводится к поддержке, где PEAP является победителем.