Theo tôi hiểu, EAP-TTLS và PEAP có chung mức độ bảo mật khi được triển khai trong các mạng không dây. Cả hai chỉ cung cấp xác thực phía máy chủ thông qua chứng chỉ.

Hạn chế của EAP-TTLS có thể không hỗ trợ riêng trong Microsoft Windows để mọi người dùng phải cài đặt phần mềm bổ sung.

Lợi ích của EAP-TTLS có thể là hỗ trợ cho các cơ chế xác thực kém an toàn (PAP, CHAP, MS-CHAP) nhưng tại sao bạn lại cần chúng trong hệ thống không dây hiện đại và an toàn đúng cách?

Ý kiến ​​của bạn là gì? Tại sao tôi nên triển khai EAP-TTLS thay vì PEAP? Hãy nói rằng tôi có hầu hết người dùng Windows, người dùng Linux trung bình và người dùng iOS, OSX ít nhất.

Bạn có thể hỗ trợ cả hai, nếu phụ trợ RADIUS của bạn hỗ trợ nó. Tuy nhiên, một số ứng dụng khách "tự động" kết nối (ví dụ Mac OS X> = 10.7 + iOS) và chúng có thể hoạt động kém tối ưu nếu bạn hỗ trợ nhiều loại, vì chúng chỉ thử các kết hợp khác nhau cho đến khi một trong số chúng hoạt động tức là chúng kết nối với ít rắc rối hơn nếu chỉ có một cách để kết nối.

Vì vậy, về cơ bản: chỉ hỗ trợ PEAP hoặc PEAP + TTLS nếu bạn có các máy khách yêu cầu TTLS.

Hạn chế của khách hàng

• khách hàng iOS sẽ không hỗ trợ EAP-TTLSvới PAP(chỉ MsCHAPv2), trừ khi bạn bằng tay (thông qua một máy tính) cài đặt một cấu hình.

• Các máy khách Windows sẽ không hỗ trợ EAP-TTLSngoài luồng (bạn sẽ cần cài đặt một phần mềm như safe2w), trừ khi chúng có thẻ không dây Intel.

• Android hỗ trợ hầu hết tất cả các kết hợp EAPvà PEAP.

Hạn chế cơ sở dữ liệu mật khẩu

Vì vậy, vấn đề thực sự là làm thế nào mật khẩu của bạn được lưu trữ.

Nếu họ ở trong:

• Active Directory , sau đó bạn có thể sử dụng EAP-PEAP-MsCHAPv2(hộp Windows) và EAP-TTLS-MsCHAPv2(với máy khách iOS).

• Nếu bạn lưu trữ mật khẩu trên LDAP , bạn có thể sử dụng EAP-TTLS-PAP(hộp Windows) nhưng bạn sẽ bị mất về iOS.

Quan tâm bảo mật quan trọng

• Cả hai EAP-TTLSvà PEAPsử dụng TLS(Bảo mật lớp vận chuyển) trên EAP(Giao thức xác thực mở rộng).

Như bạn có thể biết, TLSlà phiên bản mới hơn SSLvà hoạt động dựa trên các chứng chỉ được ký bởi cơ quan trung ương đáng tin cậy (Tổ chức chứng nhận - CA).

Để thiết lập một TLSđường hầm, khách hàng phải xác nhận rằng nó đang nói chuyện với đúng máy chủ (Trong trường hợp này, máy chủ bán kính được sử dụng để xác thực người dùng). Nó thực hiện điều đó bằng cách kiểm tra xem máy chủ có xuất trình chứng chỉ hợp lệ do CA đáng tin cậy cấp không.

Vấn đề là: thông thường, bạn sẽ không có chứng chỉ được cấp bởi một CA đáng tin cậy, nhưng chứng chỉ được cấp bởi một CA đặc biệt mà bạn đã thực hiện chỉ cho mục đích này. Hệ điều hành sẽ phàn nàn với người dùng rằng họ không biết rằng CA và người dùng (theo định hướng của bạn) sẽ vui vẻ chấp nhận điều đó.

Nhưng điều này đặt ra một rủi ro bảo mật lớn:

Ai đó có thể thiết lập một AP lừa đảo trong doanh nghiệp của bạn (trong túi hoặc thậm chí trên máy tính xách tay), định cấu hình nó để nói chuyện với máy chủ bán kính của chính mình (chạy trên máy tính xách tay của mình hoặc tại AP lừa đảo).

Nếu khách hàng của bạn thấy AP này có tín hiệu mạnh hơn thì các điểm truy cập của bạn, họ sẽ thử kết nối với nó. Sẽ thấy một CA không xác định (người dùng chấp nhận), sẽ thiết lập một TLSđường hầm, sẽ gửi thông tin xác thực trên đường hầm này và bán kính giả mạo sẽ ghi lại nó.

Bây giờ là phần quan trọng: nếu bạn đang sử dụng sơ đồ xác thực văn bản thuần túy ( PAPví dụ), máy chủ bán kính giả mạo sẽ có quyền truy cập vào mật khẩu người dùng của bạn.

Bạn có thể giải quyết điều đó bằng cách sử dụng chứng chỉ hợp lệ do Tổ chức chứng nhận cả iOS, Windows (và Android) cấp. Hoặc, bạn có thể phân phối chứng chỉ gốc CA cho người dùng của mình và thông báo cho họ từ chối kết nối khi họ gặp vấn đề về chứng chỉ (chúc may mắn với điều đó).

PEAPv0, PEAPv1 và TTLS có cùng thuộc tính bảo mật.

PEAP là một trình bao bọc SSL xung quanh EAP mang EAP. TTLS là một trình bao bọc SSL xung quanh các TLV đường kính mang các thuộc tính xác thực RADIUS.

EAP-TTLS-PAP có thể hữu ích trên EAP-PEAP nếu cơ sở dữ liệu xác thực phụ trợ lưu trữ thông tin xác thực ở định dạng băm không thể đảo ngược như bigcrypt hoặc bất kỳ hình thức nào không tương thích với MSCHAP (NT-OWF) Trong trường hợp này không thể xác thực bằng cách sử dụng bất kỳ phương pháp dựa trên CHAP.

Mặc dù bạn cũng có thể mô phỏng PAP bằng EAP-PEAPv1-GTC nhưng điều này không được khách hàng hỗ trợ rộng rãi.

PEAP có thêm một số hành lý trên TTLS dưới dạng đau đầu đàm phán phiên bản PEAP và sự không tương thích lịch sử trong PEAPv1 (Chẳng hạn như phép thuật của khách hàng khi lấy khóa chính từ PRF) đã được triển khai sớm.

Tôi thường thấy EAP-TTLS được triển khai trong các máy khách nhúng như các mô đun thuê bao trong thiết bị không dây với PEAP được sử dụng nhiều hơn bởi máy tính xách tay và thiết bị cầm tay di động.

EAP-TTLS trước đây không được hỗ trợ trong các máy khách Windows mà không phải cài đặt phần mềm của bên thứ ba. EAP-TTLS hiện được hỗ trợ bắt đầu với Windows 8.

Một số suy nghĩ bổ sung:

EAP-TTLS được phát minh bởi một nhà cung cấp RADIUS. EAP-PEAPv0 được phát minh bởi Microsoft. EAP-PEAPv1 ra đời từ quy trình IETF.

Có một số IETF bổ sung hoạt động trên PEAPv2, điều này sẽ giúp hệ thống an toàn hơn bằng cách liên kết tiền điện tử với các phương thức xác thực bên trong. Điều này đã không đi bất cứ nơi nào gần như tôi có thể nói.

Như trình ăn đĩa đã viết, lý do chính khiến mọi người sử dụng TTLS là bạn có thể cho phép máy chủ bán kính của bạn xem mật khẩu Cleartext theo cách đó, có thể hữu ích tùy thuộc vào phụ trợ xác thực của bạn.

Một xem xét mới hơn có thể ủng hộ PEAP là SoH là AFAICT chỉ được trình bày cho máy chủ RADIUS nếu nó yêu cầu và cách duy nhất để yêu cầu nó trên các hệ thống của Microsoft là trong phiên PEAP. Vì vậy, nếu bạn muốn đưa đánh giá giống như đại lý ra khỏi đánh giá không có tác nhân (có thể hỗ trợ bởi nhiều nhà cung cấp AV hơn), bạn sẽ muốn PEAP, tuy nhiên nếu bạn đang tìm cách khắc phục phụ trợ OAUTH 1 yếu tố bằng cách lấy mật khẩu trần (vì Chết tiệt, các IDP lớn sẽ không cung cấp dịch vụ đường hầm bên trong xứng đáng không kém và người dùng của họ không đủ khả năng để nhập nó) sử dụng TTLS.

Bạn phải xem xét phương thức EAP nào mà máy khách hỗ trợ nguyên bản so với phần mềm bổ sung và phương thức xác thực bên trong mà máy chủ hỗ trợ.

PEAP và EAP-TTLS được thiết kế để cho phép bạn xác thực danh tính của máy chủ, nhưng bạn phải đảm bảo rằng các máy khách được cấu hình đúng để xác thực chứng chỉ.

PEAP và MS-CHAPv2 được khách hàng hỗ trợ tốt, nhưng nếu máy chủ của bạn không hỗ trợ MS-CHAPv2 (vì bạn không lưu trữ mật khẩu Cleartext), bạn phải đưa ra giải pháp khác. Đó là lý do chính bạn sẽ thấy mọi người sử dụng EAP-TTLS và PAP.

Tôi nghĩ tự động kết nối sẽ được hưởng lợi từ cả hai tùy chọn, càng nhiều tùy chọn thì càng ít rắc rối ... ví dụ. nếu kết nối tự động thử TTLS-PAP trước và sau đó là PEAP-MSCHAP, thì tự động kết nối sẽ nhanh hơn với TTLS-PAP có sẵn. Về cơ bản: hỗ trợ cả hai, tôi không thể thấy bất lợi.

Vì bảo mật MSCHAP bị phá vỡ (google cho "crack mschap") pap với mật khẩu Cleartext thông qua ttls có cùng mức bảo mật như PEAP-MSCHAP.

Tôi không biết về bất kỳ sự khác biệt nào về bảo mật giữa EAP-TTLS và PEAP, vì vậy về cơ bản, nó sẽ hỗ trợ, trong đó PEAP là người chiến thắng.