ตามที่ฉันเข้าใจ EAP-TTLS และ PEAP มีระดับความปลอดภัยเท่ากันเมื่อใช้งานในเครือข่ายไร้สาย ทั้งสองให้การรับรองความถูกต้องฝั่งเซิร์ฟเวอร์ผ่านใบรับรองเท่านั้น

ข้อเสียของ EAP-TTLS อาจไม่ใช่การสนับสนุนดั้งเดิมใน Microsoft Windows ดังนั้นผู้ใช้ทุกคนจะต้องติดตั้งซอฟต์แวร์เพิ่มเติม

ประโยชน์ของ EAP-TTLS สามารถรองรับกลไกการพิสูจน์ตัวตนที่มีความปลอดภัยน้อยกว่า (PAP, CHAP, MS-CHAP) แต่ทำไมคุณต้องใช้พวกมันในระบบไร้สายที่ทันสมัยและปลอดภัย?

คุณมีความคิดเห็นอย่างไร? เหตุใดฉันจึงควรใช้ EAP-TTLS แทน PEAP สมมติว่าฉันมีผู้ใช้ Windows ส่วนใหญ่ผู้ใช้ Linux ปานกลางและ iOS ผู้ใช้ OSX น้อยที่สุด

คุณสามารถรองรับได้ทั้งสองถ้าแบ็กเอนด์ RADIUS ของคุณรองรับ อย่างไรก็ตามลูกค้าบางคน "auto" - เชื่อมต่อ (เช่น Mac OS X> = 10.7 + iOS) และพวกเขาอาจทำงานได้น้อยกว่าที่ดีที่สุดหากคุณรองรับมากกว่าหนึ่งประเภทเนื่องจากพวกเขาลองชุดค่าผสมที่แตกต่างกันจนกว่าพวกเขาจะทำงาน ไม่ยุ่งยากหากมีวิธีเชื่อมต่อเพียงวิธีเดียว

ดังนั้นโดยทั่วไป: สนับสนุน PEAP เท่านั้นหรือ PEAP + TTLS หากคุณมีลูกค้าที่ต้องการ TTLS

ข้อ จำกัด ลูกค้า

• ไคลเอ็นต์ iOSจะไม่สนับสนุนEAP-TTLSด้วยPAP(เท่านั้นMsCHAPv2) หากคุณไม่ได้ติดตั้งโปรไฟล์ด้วยตนเอง (ผ่านคอมพิวเตอร์)

• ไคลเอนต์ Windowsจะไม่สนับสนุนEAP-TTLSนอกกรอบ (คุณจะต้องติดตั้งซอฟต์แวร์เช่น secure2w) เว้นแต่ว่าพวกเขามีการ์ดไร้สายของ Intel

• Androidสนับสนุนเกือบทั้งหมดรวมกันของและEAPPEAP

ข้อ จำกัด ฐานข้อมูลรหัสผ่าน

ดังนั้นปัญหาที่แท้จริงคือวิธีการจัดเก็บรหัสผ่านของคุณ

หากพวกเขาอยู่ใน:

• Active Directoryจากนั้นคุณสามารถใช้EAP-PEAP-MsCHAPv2(กล่อง Windows) และEAP-TTLS-MsCHAPv2(กับไคลเอนต์ iOS)

• หากคุณเก็บรหัสผ่านไว้ในLDAPคุณสามารถใช้EAP-TTLS-PAP(กล่อง Windows) แต่คุณจะพลาดเกี่ยวกับ iOS

ข้อกังวลด้านความปลอดภัยที่สำคัญ

• ทั้งEAP-TTLSและPEAPใช้TLS(Transport Layer Security) เหนือEAP(Extensible Authentication Protocol)

ดังที่คุณอาจทราบว่าTLSเป็นรุ่นที่ใหม่กว่าSSLและทำงานตามใบรับรองที่ลงนามโดยหน่วยงานกลางที่เชื่อถือได้

เพื่อสร้างTLSอุโมงค์ลูกค้าต้องยืนยันว่ากำลังพูดคุยกับเซิร์ฟเวอร์ที่ถูกต้อง (ในกรณีนี้เซิร์ฟเวอร์รัศมีที่ใช้ในการตรวจสอบผู้ใช้) โดยการตรวจสอบว่าเซิร์ฟเวอร์แสดงใบรับรองที่ถูกต้องซึ่งออกโดย CA ที่เชื่อถือได้หรือไม่

ปัญหาคือ: โดยปกติคุณจะไม่ได้รับใบรับรองที่ออกโดย CA ที่เชื่อถือได้ แต่ใบรับรองที่ออกโดย ad-hoc CA ที่คุณสร้างขึ้นเพื่อจุดประสงค์นี้เท่านั้น ระบบปฏิบัติการจะบ่นกับผู้ใช้ว่าไม่รู้ว่า CA และผู้ใช้ (ตามที่คุณมุ่งเน้น) จะยอมรับอย่างมีความสุข

แต่สิ่งนี้มีความเสี่ยงด้านความปลอดภัยที่สำคัญ:

บางคนสามารถตั้งค่า AP อันธพาลภายในธุรกิจของคุณ (ในถุงหรือบนแล็ปท็อป) กำหนดค่าเพื่อพูดคุยกับเซิร์ฟเวอร์รัศมีของเขา (ทำงานบนแล็ปท็อปของเขาหรือที่ AP ปลอมของตัวเอง)

หากลูกค้าของคุณพบว่า AP นี้มีสัญญาณที่แรงกว่าจุดเชื่อมต่อของคุณพวกเขาจะลองเชื่อมต่อกับมัน จะเห็น CA ที่ไม่รู้จัก (ผู้ใช้ยอมรับ) จะสร้างTLSอุโมงค์และจะส่งข้อมูลการรับรองความถูกต้องในอุโมงค์นี้และรัศมีการโกงจะเข้าสู่ระบบ

ตอนนี้ส่วนที่สำคัญ: หากคุณใช้รูปแบบการรับรองความถูกต้องของข้อความล้วน ( PAPตัวอย่าง) เซิร์ฟเวอร์ radius รัศมีจะเข้าถึงรหัสผ่านผู้ใช้ของคุณ

คุณสามารถแก้ไขได้โดยใช้ใบรับรองที่ถูกต้องซึ่งออกโดยผู้ออกใบรับรองทั้ง iOS, Windows (และ Android) ที่เชื่อถือได้ หรือคุณสามารถแจกจ่ายใบรับรองหลัก CA ให้กับผู้ใช้ของคุณและแจ้งให้พวกเขาปฏิเสธการเชื่อมต่อเมื่อพวกเขาเห็นปัญหาใบรับรอง (ขอให้โชคดี)

PEAPv0, PEAPv1 และ TTLS มีคุณสมบัติความปลอดภัยเหมือนกัน

PEAP เป็นตัวห่อ SSL รอบ EAP ที่ถือ EAP TTLS เป็น SSL wrapper ขนาดเส้นผ่านศูนย์กลาง 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 ซึ่งจะทำให้ระบบมีความปลอดภัยมากขึ้นโดยการผูก crypto กับวิธีการตรวจสอบภายใน สิ่งนี้ไม่ได้หายไปไหนใกล้เท่าที่ฉันจะบอกได้

ตามที่ผู้เขียนดิสก์ไดรฟ์เหตุผลหลักที่ผู้ใช้ใช้ TTLS คือคุณสามารถอนุญาตให้เซิร์ฟเวอร์ radius ของคุณเห็นรหัสผ่าน cleartext ในลักษณะนั้นซึ่งอาจมีประโยชน์ขึ้นอยู่กับแบ็กเอนด์การพิสูจน์ตัวตนของคุณ

ข้อควรพิจารณาที่ใหม่กว่าซึ่งอาจสนับสนุน PEAP คือ SoH เป็น AFAICT นำเสนอเฉพาะกับเซิร์ฟเวอร์ RADIUS หากมีการขอและวิธีเดียวที่จะขอได้ในระบบ Microsoft คือในระหว่างเซสชัน PEAP ดังนั้นหากคุณต้องการได้รับการประเมินแบบตัวแทนจากการประเมินแบบไร้ตัวแทน (การสนับสนุนจากผู้จำหน่าย AV ที่กำลังจะมาถึง) คุณต้องการ PEAP อย่างไรก็ตามหากคุณกำลังมองหาแบ็กเอนด์ OAUTH แบบ 1 ปัจจัยด้วยการใช้รหัสผ่านเปล่า (เพราะ heck, IDP ขนาดใหญ่ที่จะไม่ให้บริการอุโมงค์ภายในควรได้รับค่าตอบแทนไม่น้อยและผู้ใช้ของพวกเขาไม่มีความสามารถพอที่จะพิมพ์) ใช้ TTLS

คุณต้องพิจารณาว่า EAP วิธีใดที่ไคลเอ็นต์รองรับด้วยวิธีดั้งเดิมกับซอฟต์แวร์เพิ่มเติมและวิธีการรับรองความถูกต้องภายในที่เซิร์ฟเวอร์รองรับ

PEAP และ EAP-TTLS ได้รับการออกแบบมาเพื่อให้คุณตรวจสอบความถูกต้องของเซิร์ฟเวอร์ แต่คุณต้องตรวจสอบให้แน่ใจว่าลูกค้าได้รับการกำหนดค่าอย่างถูกต้องเพื่อตรวจสอบใบรับรอง

PEAP และ MS-CHAPv2 ได้รับการสนับสนุนอย่างดีจากลูกค้า แต่ถ้าเซิร์ฟเวอร์ของคุณไม่รองรับ MS-CHAPv2 (เพราะคุณไม่ได้จัดเก็บรหัสผ่าน cleartext) คุณต้องหาวิธีแก้ปัญหาอื่น นั่นคือเหตุผลหลักที่คุณจะเห็นผู้คนใช้ EAP-TTLS และ PAP

ฉันคิดว่าการเชื่อมต่ออัตโนมัติจะได้ประโยชน์จากตัวเลือกทั้งสองตัวเลือกยิ่งยุ่งยากน้อยลง ... เช่น หากการเชื่อมต่ออัตโนมัติพยายาม TTLS-PAP ก่อนจากนั้น PEAP-MSCHAP การเชื่อมต่ออัตโนมัติจะเร็วขึ้นเมื่อใช้ TTLS-PAP โดยพื้นฐานแล้ว: สนับสนุนทั้งคู่ฉันไม่เห็นข้อเสีย

เนื่องจากการรักษาความปลอดภัย MSCHAP เสีย (google สำหรับ "crack mschap") pap ด้วยรหัสผ่าน cleartext ผ่าน ttls จึงมีระดับความปลอดภัยเท่ากับ PEAP-MSCHAP

ฉันไม่ทราบถึงความแตกต่างด้านความปลอดภัยระหว่าง EAP-TTLS และ PEAP ดังนั้นโดยพื้นฐานแล้วมันก็สนับสนุนการใช้งานโดยที่ PEAP เป็นผู้ชนะ