Bảo mật & xác thực: SSL vs SASL

Question

Sự hiểu biết của tôi là SSL kết hợp thuật toán mã hóa (như AES, DES, v.v.) với phương thức trao đổi khóa (như Diffier-Hellman) để cung cấp dịch vụ mã hóa và nhận dạng an toàn giữa hai điểm cuối một mạng không an toàn (như Internet).

Sự hiểu biết của tôi là SASL là giao thức MD5/Kerberos, thực hiện tương tự như vậy.

Vì vậy, câu hỏi của tôi: những ưu điểm/khuyết điểm để lựa chọn cả hai và kịch bản nào làm cho một trong hai thích hợp hơn? Về cơ bản, tôi đang tìm một số hướng dẫn để làm theo khi chọn SSL hoặc để đi với SASL thay thế. Cảm ơn trước!

Answer 1

Khá khó để so sánh SSL/TLS và SASL, vì SSL/TLS là giao thức truyền thông, trong khi SASL là một khuôn khổ, được tích hợp với các giao thức khác. (Trong thực tế, bạn có thể sử dụng cả hai cùng một lúc trong một số trường hợp.)

Ngoài ra, bạn đang đề cập đến Kerberos, thực sự là giao thức xác thực (có thể được sử dụng với SSL/TLS hoặc SASL hoặc độc lập cả hai)). Câu hỏi của bạn dường như gợi ý rằng có hay không sử dụng Kerberos một trong những vấn đề phụ chính bạn nên chọn trước tiên. SAS2 về cơ bản là một lớp hướng dẫn để cho phép các hệ thống xác thực có thể cắm và bảo mật dữ liệu trong các giao thức ứng dụng hiện có (ví dụ LDAP, SMTP, Subversion, ...), mặc dù các giao thức này cần phải biết phần mở rộng này (ví dụ: SMTP auth) . Cho dù và làm thế nào nó cung cấp xác thực an toàn và mã hóa dữ liệu phụ thuộc rất nhiều vào những gì underlying mechanism được sử dụng trong khuôn khổ này. Dưới đây là ví dụ từ svnserve documentation: "Cơ chế CRAM-MD5 được tích hợp sẵn không hỗ trợ mã hóa, nhưng DIGEST-MD5 thực hiện". Nếu bạn muốn sử dụng Kerberos với SASL, bạn sẽ cần một mức độ khác nhau: GSS-API (được sử dụng phổ biến nhất với Kerberos, nhưng cũng có thể cho phép các cơ chế khác). (Lưu ý rằng GSSAPI trong ngữ cảnh SASL dường như ngụ ý Kerberos, không giống như GS2 successor.)

Mục tiêu chung của SSL/TLS là đảm bảo giao tiếp (tính toàn vẹn và bảo mật) giữa máy khách và máy chủ. Khách hàng phải luôn kiểm tra danh tính của máy chủ SSL/TLS và nó cung cấp các cơ chế cho máy chủ để kiểm tra danh tính của máy khách. Những gì nó có thể làm cũng phụ thuộc vào cách nó được cấu hình. SSL/TLS thường được sử dụng nhất với chứng chỉ X.509: đó là cách trình duyệt có thể kiểm tra danh tính của máy chủ HTTPS. Các máy chủ cũng có thể được cấu hình để yêu cầu máy khách sử dụng một chứng chỉ để tự nhận dạng (xác thực chứng chỉ ứng dụng khách). Tuy nhiên, nếu bạn muốn sử dụng Kerberos, bạn có thể sử dụng TLS Kerberos cipher suites. Điều này ít phổ biến hơn, nhưng chúng là implemented in the JSSE.

Việc triển khai thường cung cấp API tương tự như những gì bạn nhận được với kết nối TCP đơn giản: trong Java, sau khi được định cấu hình, bạn có thể sử dụng số ít SSLSocket khi sử dụng số Socket. Điều này không yêu cầu nhận thức cụ thể bởi giao thức trên đỉnh của socket, mặc dù một số giao thức có lệnh rõ ràng để chuyển sang SSL/TLS từ một kết nối đơn giản (Implicit v.s. Explicit SSL/TLS). Nó cũng có thể cung cấp xác thực. Trong Java, JSSE là triển khai SSL/TLS mặc định, cho phép bạn truy cập vào SSLSocket (hoặc SSLEngine nếu bạn đủ can đảm).

Bạn có thể muốn đọc "When to use Java GSS-API vs. JSSE", mà là tương tự như "SASL vs SSL/TLS" (mặc dù nó không có vẻ đã được cập nhật cho một thời gian, kể từ khi JSSE không hỗ trợ dãy Kerberos mật mã bây giờ, ít nhất là từ Oracle Java 6).

Tôi sẽ thừa nhận rằng tôi biết ít hơn về SASL so với SSL/TLS, nhưng việc mã hóa dữ liệu qua SASL có vẻ như nó sẽ hoạt động hiệu quả hơn. Dường như có một số tính năng SSL/TLS nhất định chẳng hạn như Perfect Forward Secrecy offered by EDH cipher suites. Có một example that uses SASL with GSSAPI (Kerberos here) in the JGSS tutorial: bạn cần phải bao bọc/mở rộng dữ liệu một cách rõ ràng, bạn sẽ không phải làm gì khi sử dụng SSLSocket s.

Tôi nghĩ rằng mối quan tâm chính của bạn nên là quyết định cơ chế xác thực nào bạn muốn sử dụng ở nơi đầu tiên: Kerberos, chứng chỉ X.509 hoặc một thứ khác. Điều này sẽ có tác động nhiều hơn đến kiến ​​trúc tổng thể của bạn, và cả hai có thể được sử dụng với SASL và SSL/TLS (nhiều hơn như vậy nếu bạn sử dụng SASL với một cơ chế EXTERNAL, khi trên đầu trang của một kết nối SSL/TLS).

• Kerberos rất tập trung. Khách hàng sẽ cần có khả năng liên hệ với KDC để xác thực, ngoài việc có thể liên hệ với máy chủ ứng dụng của bạn. Các máy khách cũng sẽ cần được cấu hình để sử dụng KDC đó. Từ quan điểm của người dùng, họ có thể sử dụng mật khẩu.
• X.509 được phân cấp hơn. Tuy nhiên, bạn có thể cần triển khai một Tổ chức phát hành chứng chỉ (hoặc sử dụng một cơ quan cấp phép thương mại) cho các chứng chỉ người dùng của bạn. Người dùng sẽ cần được cấp chứng chỉ và khóa riêng tư, một số có thể quá phức tạp.

JAAS đi vào trong vì đó là khung Java chung để xử lý xác thực và ủy quyền. Nó được liên kết rất chặt chẽ với khái niệm của các nhà quản lý an ninh. Nó cung cấp cho bạn khái niệm về Subject and Principal. Điều này không liên quan trực tiếp đến các giao thức hoặc giao tiếp, mà là cách bạn mô hình xác thực và ủy quyền trong ứng dụng của bạn. (Nó cung cấp cho bạn một tập hợp các lớp tiêu chuẩn để làm như vậy.)

(Tôi thường đề nghị xem qua số Java reference documents đề cập đến những từ bạn đang theo sau: JGSS, SASL, ..., mặc dù chúng không nhất thiết phải dễ đọc.)

Answer 2

SASL không phải là giao thức mà là lớp trừu tượng đối với một số cơ chế xác thực. Nếu bạn sử dụng Digest-MD5 hoặc GSS-API làm cơ chế SASL, bạn có thể yêu cầu SASL mã hóa hoàn toàn lưu lượng dữ liệu của bạn. Đây là ví dụ những gì tôi làm để nói chuyện với các máy chủ Active Directory của bạn. Bạn sẽ không cần SSL. Trường hợp sử dụng của bạn là gì. Xin hãy giải thích!

Answer 3

SSL vs SASL

Đúng là SASL không phải là một giao thức mà là một lớp trừu tượng. Nó cũng đúng là SSL và SASL là loại cung cấp các tính năng tương tự. Cả hai đều cung cấp xác thực, ký dữ liệu và mã hóa.

SSL được thực hiện ở lớp vận chuyển và nó là thông thường trong suốt đối với giao thức bên dưới. Ví dụ: bạn có thể sử dụng SSL trên LDAP hoặc HTTP. Tuy nhiên, trong một số trường hợp, việc sửa đổi các giao thức hiện có là cần thiết để chuyển sang chế độ bảo mật. Ví dụ, POP3 và IMAP được mở rộng để có lệnh STARTTLS để bắt đầu sử dụng SSL. Từ góc độ đó, đây là loại tương tự như những gì SASL đang làm.

Mặt khác, nhiều giao thức cũng được mở rộng để cung cấp khả năng SASL. Here là danh sách các giao thức. Một lần nữa, POP3 và IMAP là hai trong số họ và họ đang sử dụng các lệnh khác nhau để bắt đầu xác thực.

Vì vậy, khi nào chúng ta nên sử dụng SSL và khi nào chúng ta nên sử dụng SASL?

Sự khác biệt rõ ràng giữa SSL và SASL là SASL cho phép bạn chọn các cơ chế khác nhau để xác thực máy khách trong khi SSL là loại ràng buộc để thực hiện xác thực dựa trên chứng chỉ. Trong SASL, bạn có thể chọn sử dụng GSSAPI, Kerberos, NTLM, v.v.

Vì sự khác biệt này, có một số trường hợp, nó chỉ trực quan hơn để sử dụng SASL chứ không phải SSL. Ví dụ: ứng dụng khách của bạn đang sử dụng Kerberos để xác thực người dùng cuối. Máy chủ của bạn cần xác thực ứng dụng khách. Vì ứng dụng khách của bạn đã có thông tin đăng nhập Kerberos (trong thuật ngữ Kerberos, một vé), nên sử dụng thông tin đăng nhập Kerberos để xác thực với máy chủ. Tất nhiên, bạn luôn có thể thiết lập SSL để làm điều tương tự. Tuy nhiên, điều đó có nghĩa là trên cơ sở hạ tầng Kerberos hiện có, bạn cần phải thiết lập cơ sở hạ tầng Authority Authority và bằng cách nào đó tương quan chứng chỉ ứng dụng khách với thông tin đăng nhập Kerberos. Đó là doable nhưng rất nhiều công việc.

Ngoài ra, đôi khi, bạn cần sử dụng một số tính năng chỉ có sẵn trong cơ chế SASL chứ không phải SSL. Ví dụ: Kerberos cho phép bạn chuyển tiếp vé từ máy khách đến máy chủ để máy chủ có thể sử dụng vé để truy vấn một số tài nguyên thay mặt cho máy khách. Một ví dụ phổ biến là bạn có một máy chủ ứng dụng và một cơ sở dữ liệu. Ứng dụng máy khách xác thực với máy chủ ứng dụng và máy chủ ứng dụng cần truy vấn cơ sở dữ liệu để xử lý ứng dụng khách bằng thông tin đăng nhập của máy khách. SSL không thể cung cấp tính năng này cho bạn nhưng Kerberos hỗ trợ tính năng này. Vì vậy, trong trường hợp đó, bạn phải chọn sử dụng SASL.

Trong một số trường hợp, bạn muốn sử dụng SSL nhưng không sử dụng SASL. Ví dụ, mở rộng giao thức không phải là một lựa chọn hoặc bạn muốn mã hóa mọi gói tin được trao đổi bằng cách sử dụng giao thức bên dưới.

như thế nào GSSAPI liên quan đến Kerberos và SASL

Theo wiki page này, cả hai GSSAPI và Kerberos được hỗ trợ mechansim trong SASL. GSSAPI là một giao diện lập trình chung. Ý tưởng là để cho người viết ứng dụng sử dụng một API chung duy nhất để thực hiện xác thực, mã hóa, v.v. bất kể giao thức nào được sử dụng bên dưới. GSSAPI triển khai Kerberos. Vì vậy, bạn có thể sử dụng GSSAPI để thực hiện xác thực Kerberos.

như thế nào JAAS liên quan đến SASL

Thành thật mà nói, tôi không phải là một chuyên gia về Java. Từ những gì tôi đọc, có vẻ như JAAS chỉ là một khung xác thực có thể cắm được. Tôi tin rằng ý tưởng này tương tự như GSSAPI. Nó cung cấp một giao diện lập trình duy nhất bất kể phương thức xác thực đang sử dụng là gì. Trong khi GSSAPI tập trung vào trao đổi thông điệp xác thực và bảo mật, JAAS đang tập trung vào xác thực và ủy quyền. Tôi không tìm thấy bằng chứng nào cho thấy JAAS cũng là một trong những cơ chế SASL. Tôi tin rằng cần có một số lớp trợ giúp từ thư viện Java giúp bạn triển khai các cơ chế SASL tùy chỉnh. Trong khi thực hiện cơ chế SASL tùy chỉnh, nó có thể có ý nghĩa để chỉ sử dụng JAAS.