Zrozumiałem, że EAP-TTLS i PEAP mają ten sam poziom bezpieczeństwa, gdy są wdrażane w sieciach bezprzewodowych. Oba zapewniają uwierzytelnianie po stronie serwera tylko za pomocą certyfikatu.

Wadą EAP-TTLS może być nienatywna obsługa w systemie Microsoft Windows, dlatego każdy użytkownik musi zainstalować dodatkowe oprogramowanie.

Zaletą EAP-TTLS może być obsługa mniej bezpiecznych mechanizmów uwierzytelniania (PAP, CHAP, MS-CHAP), ale dlaczego miałbyś ich potrzebować w nowoczesnym i odpowiednio bezpiecznym systemie bezprzewodowym?

Jakie są twoje opinie Dlaczego powinienem wdrożyć EAP-TTLS zamiast PEAP? Powiedzmy, że mam większość użytkowników systemu Windows, średnich użytkowników Linuksa, a najmniej iOS, OSX.

Możesz obsługiwać oba, jeśli backend RADIUS je obsługuje. Jednak niektóre „automatyczne” połączenia klientów (na przykład Mac OS X> = 10,7 + iOS) i mogą działać mniej niż optymalnie, jeśli obsługuje się więcej niż jeden typ, ponieważ po prostu wypróbowują różne kombinacje, dopóki jedno z nich nie zadziała, tzn. Połączą się bez kłopotów, jeśli istnieje tylko jeden sposób połączenia.

Zasadniczo: obsługuj tylko PEAP lub PEAP + TTLS, jeśli masz klientów wymagających TTLS.

Ograniczenia klienta

• Klienci iOS nie wesprze EAP-TTLSz PAP(tylko MsCHAPv2), chyba że ręcznie (za pomocą komputera) zainstalować profil.

• Klienci Windows nie będą obsługiwać EAP-TTLSgotowych urządzeń (musisz zainstalować oprogramowanie takie jak secure2w), chyba że mają karty bezprzewodowe Intel.

• Android obsługuje prawie wszystkie kombinacje EAPi PEAP.

Ograniczenia bazy danych haseł

Tak więc prawdziwym problemem jest sposób przechowywania haseł.

Jeśli są w:

• Active Directory , wtedy możesz używać EAP-PEAP-MsCHAPv2(Windows box) i EAP-TTLS-MsCHAPv2(z klientami iOS).

• Jeśli przechowujesz hasła na LDAP , możesz użyć EAP-TTLS-PAP(Windows box), ale stracisz połączenie z iOS.

Ważne obawy dotyczące bezpieczeństwa

• Zarówno EAP-TTLSi PEAPużyj TLS(Transport Layer Security) EAPzamiast (Extensible Authentication Protocol).

Jak zapewne wiesz, TLSjest nowszą wersją SSLi działa w oparciu o certyfikaty podpisane przez zaufany organ centralny (Urząd Certyfikacji - CA).

Aby ustanowić TLStunel, klient musi potwierdzić, że rozmawia z właściwym serwerem (w tym przypadku serwer promienia używany do uwierzytelniania użytkowników). Dokonuje tego, sprawdzając, czy serwer przedstawił prawidłowy certyfikat wystawiony przez zaufany urząd certyfikacji.

Problem polega na tym, że normalnie nie będziesz mieć certyfikatu wydanego przez zaufany urząd certyfikacji, ale certyfikat wydany przez urząd certyfikacji ad hoc utworzony właśnie w tym celu. System operacyjny będzie skarżył się użytkownikom, że nie wie, że urząd certyfikacji i użytkownicy (zgodnie z twoimi wskazówkami) chętnie to zaakceptują.

Ale stwarza to poważne zagrożenie bezpieczeństwa:

Ktoś może skonfigurować nieuczciwy AP w Twojej firmie (w torbie lub nawet na laptopie), skonfigurować go tak, aby rozmawiał ze swoim własnym serwerem radiowym (działającym na swoim laptopie lub na własnym nieuczciwym AP).

Jeśli Twoi klienci stwierdzą, że ten AP ma silniejszy sygnał niż Twoje punkty dostępu, spróbują się z nim połączyć. Zobaczy nieznany urząd certyfikacji (użytkownicy akceptują), ustanowi TLStunel, wyśle ​​informacje uwierzytelniające w tym tunelu, a fałszywy promień go zarejestruje.

Teraz ważna część: jeśli używasz schematu uwierzytelniania zwykłego tekstu ( PAPna przykład), nieuczciwy serwer radius będzie miał dostęp do haseł użytkowników.

Możesz rozwiązać ten problem, używając ważnego certyfikatu wydanego przez urząd certyfikacji zarówno dla systemu iOS, Windows (i Android). Lub możesz rozpowszechnić certyfikat główny urzędu certyfikacji wśród użytkowników i poinformować ich, aby odmówili połączenia, gdy zobaczą problemy z certyfikatem (powodzenia).

PEAPv0, PEAPv1 i TTLS mają te same właściwości bezpieczeństwa.

PEAP to opakowanie SSL dookoła EAP zawierające EAP. TTLS to opakowanie SSL wokół TLV o średnicy z atrybutami uwierzytelniania RADIUS.

EAP-TTLS-PAP może być przydatny w porównaniu z EAP-PEAP, jeśli poświadczenia bazy danych uwierzytelniania zaplecza przechowują w nieodwracalnym formacie skrótu, takim jak bigcrypt lub w dowolnej formie niezgodnej z MSCHAP (NT-OWF). W takim przypadku uwierzytelnienie przy użyciu dowolna z metod opartych na CHAP.

Chociaż można również emulować PAP za pomocą EAP-PEAPv1-GTC, nie jest to tak szeroko obsługiwane przez klientów.

PEAP ma dodatkowy bagaż w stosunku do TTLS w postaci bólów negocjacyjnych wersji PEAP i historycznych niezgodności w PEAPv1 (takich jak magia klienta przy uzyskiwaniu klucza głównego z PRF), które weszły do ​​wczesnych wdrożeń.

Zwykle widzę, że EAP-TTLS jest implementowany we wbudowanych klientach, takich jak moduły abonenckie w sprzęcie bezprzewodowym, a PEAP jest częściej używany przez laptopy i telefony komórkowe.

EAP-TTLS w przeszłości nie był obsługiwany w klientach Windows bez konieczności instalowania oprogramowania innych firm. EAP-TTLS jest teraz obsługiwany począwszy od systemu Windows 8.

Kilka dodatkowych myśli:

EAP-TTLS został wymyślony przez dostawcę RADIUS. EAP-PEAPv0 został wymyślony przez Microsoft. EAP-PEAPv1 wyszedł z procesu IETF.

Wprowadzono pewne dodatkowe prace IETF nad PEAPv2, które zwiększyłyby bezpieczeństwo systemu dzięki powiązaniom kryptograficznym z wewnętrznymi metodami uwierzytelniania. To nie zbliżyło się tak blisko, jak mogę powiedzieć.

Jak napisał zjadacz dysku, głównym powodem, dla którego ludzie używają TTLS, jest to, że możesz pozwolić swojemu serwerowi radius zobaczyć w ten sposób hasło w postaci czystego tekstu, co może być przydatne w zależności od backendu uwierzytelnienia.

Nowszą kwestią, która może faworyzować PEAP, jest to, że SoH jest AFAICT prezentowany tylko serwerowi RADIUS, jeśli o to poprosi, a jedynym sposobem, aby o to poprosić w systemach Microsoft, jest sesja PEAP. Więc jeśli chcesz uzyskać ocenę podobną do agenta z oceny bezagentowej (prawdopodobnie pojawi się wsparcie ze strony innych dostawców AV), powinieneś PEAP, jednak jeśli chcesz obejść 1-czynnikowy backend OAUTH, biorąc nagie hasło (ponieważ cholera, duzi dostawcy IDP, którzy nie zapewnią usługi tunelu wewnętrznego, zasługują na nie mniej, a ich użytkownicy nie mają wystarczającej wiedzy, aby ją wpisać) używają TTLS.

Musisz rozważyć, jakie metody EAP klient obsługuje natywnie w porównaniu z dodatkowym oprogramowaniem i jakie wewnętrzne metody uwierzytelniania obsługuje serwer.

Protokoły PEAP i EAP-TTLS umożliwiają weryfikację tożsamości serwera, ale należy upewnić się, że klienci są odpowiednio skonfigurowani do sprawdzania poprawności certyfikatu.

PEAP i MS-CHAPv2 są dobrze obsługiwane przez klientów, ale jeśli twój serwer nie obsługuje MS-CHAPv2 (ponieważ nie przechowujesz haseł czystego tekstu), musisz znaleźć inne rozwiązanie. To główny powód, dla którego zobaczysz, że ludzie używają EAP-TTLS i PAP.

Myślę, że automatyczne połączenie skorzystałoby z obu opcji, im więcej opcji, tym mniej problemów ... np. jeśli automatyczne połączenie najpierw spróbuje TTLS-PAP, a następnie PEAP-MSCHAP, automatyczne połączenie jest szybsze przy dostępnym TTLS-PAP. Więc w zasadzie: wspieraj oba, nie widzę wady.

Ponieważ zabezpieczenia MSCHAPs są zepsute (google dla „crack mschap”), pap z hasłem w postaci czystego tekstu przez ttls ma ten sam poziom bezpieczeństwa co PEAP-MSCHAP.

Nie znam różnic w bezpieczeństwie między EAP-TTLS a PEAP, więc w zasadzie sprowadza się to do wsparcia, gdzie PEAP jest zwycięzcą.