Як я зрозумів, 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і захист транспортного шару (протокол розширюваної автентифікації).PEAPTLSEAP

Як ви знаєте, TLSце нова версія SSLта працює на основі сертифікатів, підписаних довіреним центральним органом (Орган з сертифікації - CA).

Щоб встановити TLSтунель, клієнт повинен підтвердити, що він розмовляє з правильним сервером (у цьому випадку сервер радіусів, який використовується для аутентифікації користувачів). Це робиться, перевіряючи, чи сервер представив дійсний сертифікат, виданий довіреним центром обслуговування.

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

Але це становить великий ризик для безпеки:

Хтось може налаштувати несанкціоновану AP у вашому бізнесі (у сумці чи навіть на ноутбуці), налаштувати її для розмови з власним сервером радіусу (працює на своєму ноутбуці чи на власному зловмисному AP).

Якщо ваші клієнти виявлять, що ця AP має більш сильний сигнал, ніж точки доступу, вони спробують підключитися до неї. Побачить невідомий CA (користувачі приймають), встановить 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 доступний. В основному: підтримка обох, я не бачу недоліку.

Оскільки безпека MSCHAPs порушена (google для "crack mschap"), пап із паролем cleartext через ttls має той самий рівень безпеки, що і PEAP-MSCHAP.

Я не знаю жодних відмінностей у безпеці між EAP-TTLS та PEAP, тому в основному це зводиться до підтримки, де PEAP є переможцем.