Anladığım gibi, EAP-TTLS ve PEAP kablosuz ağlarda uygulandığında aynı güvenliği paylaşıyor. Her ikisi de yalnızca sertifika yoluyla sunucu tarafı kimlik doğrulaması sağlar.

EAP-TTLS'nin dezavantajı, Microsoft Windows'da yerel olmayan destek olabilir, bu nedenle her kullanıcının ek yazılım yüklemesi gerekir.

EAP-TTLS'nin yararı, daha az güvenli kimlik doğrulama mekanizmaları (PAP, CHAP, MS-CHAP) için destek olabilir, ancak neden modern ve uygun şekilde güvenli kablosuz sistemde onlara ihtiyacınız olsun?

Ne düşünüyorsun? PEAP yerine neden EAP-TTLS uygulamalıyım? Diyelim ki çoğu Windows kullanıcısı, orta Linux kullanıcısı ve en az iOS, OSX kullanıcısı var.

RADIUS arka ucunuz destekliyorsa her ikisini de destekleyebilirsiniz. Bununla birlikte, bazı istemciler "otomatik" bağlanır (örneğin Mac OS X> = 10.7 + iOS) ve birden fazla türü desteklerseniz optimumdan daha az çalışabilirler, çünkü bunlardan biri çalışana kadar farklı kombinasyonları dener, yani bağlanırlar bağlanmak için tek bir yol varsa daha az güçlükle.

Yani Temelde: yalnızca PEAP'yi veya TTLS gerektiren müşterileriniz varsa PEAP + TTLS'yi destekleyin.

Müşteri kısıtlamaları

• Manuel olarak (bilgisayar aracılığıyla) bir profil yüklemediğiniz sürece iOS istemcileri (yalnızca ) EAP-TTLSile desteklenmez .PAPMsCHAPv2

• Windows istemcileri , EAP-TTLSIntel kablosuz kartlarına sahip olmadıkları sürece kullanıma hazır olarak desteklenmez (secure2w gibi bir yazılım yüklemeniz gerekir).

• AndroidEAP ve hemen hemen tüm kombinasyonlarını destekler PEAP.

Şifre veritabanı kısıtlamaları

Böylece, asıl sorun şifrelerinizin nasıl saklandığıdır.

İçerdeyse:

• Active Directory'yi seçtiğinizde EAP-PEAP-MsCHAPv2(Windows kutuları) ve EAP-TTLS-MsCHAPv2(iOS istemcileriyle) kullanabilirsiniz.

• Parolaları LDAP'de depolarsanız EAP-TTLS-PAP(Windows kutuları) kullanabilirsiniz, ancak iOS konusunda kaybolacaksınız.

Önemli Güvenlik Endişeleri

• Hem EAP-TTLSve PEAPkullanımı TLS(Taşıma Katmanı Güvenliği) üzerinden EAP(Genişletilebilir Kimlik Doğrulama Protokolü).

Bildiğiniz gibi, güvenilir bir merkezi otorite (Sertifika Yetkilisi - CA) tarafından imzalanan sertifikaların TLSdaha yeni bir sürümüdür SSLve çalışır.

TLSTünel oluşturmak için , istemcinin doğru sunucuyla konuştuğunu doğrulaması gerekir (Bu durumda, kullanıcıların kimliğini doğrulamak için kullanılan yarıçap sunucusu). Bunu, sunucunun güvenilen bir CA tarafından verilen geçerli bir sertifika sunup sunmadığını denetleyerek yapar.

Sorun: normalde, güvenilir bir CA tarafından verilen bir sertifikanız olmaz, ancak yalnızca bu amaçla yaptığınız geçici bir CA tarafından verilen bir sertifikanız olmaz. İşletim sistemi, kullanıcılara CA'nın ve (sizin tarafınızdan yönlendirildiği gibi) kullanıcıların bunu memnuniyetle kabul edeceğini bilmediğinden şikayet edecektir.

Ancak bu büyük bir güvenlik riski oluşturur:

Birisi işletmenizin içinde (çantada veya dizüstü bilgisayarda) sahte bir AP kurabilir, kendi yarıçap sunucusuyla (dizüstü bilgisayarında veya kendi sahte AP'sinde çalışacak şekilde) konuşacak şekilde yapılandırabilir.

İstemcileriniz bu AP'yi erişim noktalarınızdan daha güçlü bir sinyale sahip bulurlarsa, ona bağlanmaya çalışırlar. Bilinmeyen bir CA görecek (kullanıcılar kabul edecek), bir TLStünel oluşturacak, bu tünel üzerinde kimlik doğrulama bilgileri gönderecek ve haydut yarıçapı günlüğe kaydedecektir.

Şimdi önemli olan: düz metin kimlik doğrulama şeması ( PAPörneğin) kullanıyorsanız, dolandırıcılık yarıçapı sunucusu kullanıcılarınızın şifrelerine erişebilir.

Sertifika Yetkilisi tarafından verilen geçerli bir sertifikayı kullanarak hem iOS hem de Windows (ve Android) güvenini kullanarak bunu çözebilirsiniz. Veya CA kök sertifikasını kullanıcılarınıza dağıtabilir ve sertifika sorunları (bu konuda iyi şanslar) gördüklerinde bağlantıyı reddetmelerini bildirebilirsiniz.

PEAPv0, PEAPv1 ve TTLS aynı güvenlik özelliklerine sahiptir.

PEAP, EAP taşıyan EAP etrafında bir SSL paketleyicisidir. TTLS, RADIUS kimlik doğrulama özelliklerini taşıyan çap TLV'leri etrafında bir SSL paketleyicisidir.

EAP-TTLS-PAP, arka uç kimlik doğrulama veritabanı kimlik bilgilerini bigcrypt gibi ters çevrilemez bir karma biçiminde veya MSCHAP (NT-OWF) ile uyumlu olmayan herhangi bir biçimde depolarsa EAP-PEAP üzerinden faydalı olabilir. Bu durumda kullanarak kimlik doğrulaması mümkün değildir CHAP tabanlı yöntemlerden herhangi biri.

PAP'ı EAP-PEAPv1-GTC kullanarak da taklit edebilmenize rağmen, bu istemciler tarafından yaygın olarak desteklenmemektedir.

PEAP, erken uygulamalara yol açan PEAP sürüm müzakere baş ağrıları ve PEAPv1'deki (PRF'den ana anahtar türetilirken müşteri büyüsü gibi) tarihsel uyumsuzluklar şeklinde TTLS üzerinde bazı bagajlar eklemiştir.

Normalde EAP-TTLS'nin PEAP ile kablosuz cihazlarda abone modülleri gibi yerleşik istemcilerde daha çok dizüstü bilgisayarlar ve mobil telefonlar tarafından kullanıldığını görüyorum.

EAP-TTLS, Windows istemcilerinde üçüncü taraf yazılımları yüklemek zorunda kalmadan geçmişte desteklenmemiştir. EAP-TTLS artık Windows 8'den başlayarak desteklenmektedir.

Bazı ek düşünceler:

EAP-TTLS bir RADIUS satıcısı tarafından icat edildi. EAP-PEAPv0, Microsoft tarafından icat edildi. EAP-PEAPv1 IETF sürecinden çıktı.

PEAPv2 üzerinde, iç kimlik doğrulama yöntemlerine kripto bağlamaları yoluyla sistemi daha güvenli hale getirecek bazı ek IETF çalışmaları vardı. Bu benim anlayabildiğim kadar yakın bir yere gitmedi.

Disk yiyicinin yazdığı gibi, insanların TTLS'yi kullanmasının temel nedeni, radius sunucunuzun açık metin parolasını bu şekilde görmesine izin verebilmenizdir; bu, kimlik doğrulama arka ucunuza bağlı olarak faydalı olabilir.

PEAP'ı tercih edebilecek daha yeni bir husus, SoH'un yalnızca RADIUS sunucusuna isterse sunulması AFAICT olmasıdır ve Microsoft sistemlerinde sormanın tek yolu bir PEAP oturumu sırasındadır. Bu nedenle, aracısız değerlendirmeden aracıya benzer bir değerlendirme almak istiyorsanız (muhtemelen daha fazla AV satıcısı tarafından desteklenecek) PEAP istersiniz, ancak çıplak bir parola alarak 1 faktörlü bir OAUTH arka ucu etrafında çalışmak istiyorsanız (çünkü heck, iç tünel hizmeti sağlamayan büyük ÜİYOK'ler daha azını hak etmiyor ve kullanıcıları bunu yazacak kadar clueless) TTLS kullanıyorlar.

İstemcinin ek yazılımla karşılaştırıldığında yerel olarak hangi EAP yöntemlerini desteklediğini ve sunucunun hangi iç kimlik doğrulama yöntemlerini desteklediğini düşünmeniz gerekir.

PEAP ve EAP-TTLS, sunucunun kimliğini doğrulamanızı sağlamak için tasarlanmıştır, ancak istemcilerin sertifikayı doğrulayacak şekilde yapılandırıldığından emin olmanız gerekir.

PEAP ve MS-CHAPv2 istemciler tarafından iyi desteklenir, ancak sunucunuz MS-CHAPv2'yi desteklemiyorsa (açık metin parolalarını saklamadığınız için) başka bir çözüm bulmanız gerekir. İnsanların EAP-TTLS ve PAP kullandığını görmenizin ana nedeni budur.

Otomatik bağlantının her iki seçenekten de fayda sağlayacağını düşünüyorum, daha fazla seçenek daha az güçlük ... örn. otomatik bağlantı önce TTLS-PAP ve ardından PEAP-MSCHAP'yi denerse, TTLS-PAP kullanılabilir olduğunda otomatik bağlantı daha hızlıdır. Temel olarak: her ikisini de destekleyin, bir dezavantaj göremiyorum.

MSCHAP'lerin güvenliği bozulduğundan ("crack mschap" için google) ttls aracılığıyla açık metin parolası olan pap PEAP-MSCHAP ile aynı güvenlik düzeyine sahiptir.

EAP-TTLS ve PEAP arasındaki güvenlik farklarını bilmiyorum, bu yüzden temelde PEAP'ın kazanan olduğu desteklemeye geliyor.