Tôi hơi bối rối về cách thức hoạt động của SSL hai chiều. Làm thế nào để khách hàng tạo chứng chỉ của nó để gửi đến máy chủ? Nó được tạo ra từ máy chủ và phân phối cho khách hàng?Làm rõ hai chiều SSL
Ngoài ra, lợi thế của SSL hai chiều trên SSL một chiều là gì?
Cả hai chứng chỉ phải tồn tại trước khi kết nối. Chúng thường được tạo ra bởi các Tổ chức Chứng nhận (không nhất thiết phải giống nhau). (Có những trường hợp thay thế mà xác minh có thể được thực hiện khác nhau, nhưng một số xác minh sẽ cần phải được thực hiện.)
Chứng chỉ máy chủ nên được tạo ra bởi một CA mà các quỹ tín thác khách hàng (và theo đúng naming conventions quy định tại RFC 6125).
Chứng chỉ ứng dụng khách phải được tạo bởi CA mà máy chủ tin cậy.
Điều đó tùy thuộc vào mỗi bên để chọn những gì họ tin tưởng.
Có các công cụ CA trực tuyến cho phép bạn đăng ký chứng chỉ trong trình duyệt của bạn và cài đặt chứng chỉ tại đó khi CA đã phát hành. Chúng không cần trên máy chủ yêu cầu xác thực chứng chỉ ứng dụng khách.
Phân phối chứng chỉ và quản lý tin cậy là vai trò của Cơ sở hạ tầng khóa công khai (PKI), được triển khai thông qua các CA. Máy khách và máy chủ SSL/TLS và sau đó chỉ là người dùng của PKI đó.
Khi khách hàng kết nối với máy chủ yêu cầu xác thực chứng chỉ ứng dụng khách, máy chủ gửi danh sách các CA mà nó sẵn sàng chấp nhận như một phần của yêu cầu chứng chỉ ứng dụng khách. Sau đó, khách hàng có thể gửi chứng chỉ ứng dụng khách của mình, nếu muốn và có một chứng chỉ phù hợp.
Ưu điểm chính của xác thực client-Giấy chứng nhận bao gồm:
Bạn có thể quan tâm đến Advantages of client certificates for client authentication? (on Security.SE).
Những gì bạn gọi là "SSL hai chiều" thường được gọi là TLS/SSL với xác thực chứng chỉ ứng dụng khách.
Trong kết nối TLS "bình thường" đến example.com, chỉ ứng dụng khách xác minh rằng nó thực sự đang kết nối với máy chủ cho example.com. Máy chủ không biết khách hàng là ai. Nếu máy chủ muốn xác thực máy khách, điều bình thường là sử dụng mật khẩu, vì vậy máy khách cần gửi tên người dùng và mật khẩu cho máy chủ, nhưng điều này xảy ra bên trong kết nối TLS như một phần của giao thức bên trong (ví dụ: HTTP) một phần của giao thức TLS. Điểm bất lợi là bạn cần mật khẩu riêng cho mỗi trang vì bạn gửi mật khẩu cho máy chủ. Vì vậy, nếu bạn sử dụng cùng một mật khẩu trên ví dụ PayPal và MyPonyForum thì mỗi khi bạn đăng nhập vào MyPonyForum bạn gửi mật khẩu này đến máy chủ MyPonyForum để nhà điều hành máy chủ này có thể chặn nó và thử trên PayPal và có thể phát hành thanh toán bằng tên của bạn .
Xác thực chứng chỉ ứng dụng khách cung cấp một cách khác để xác thực ứng dụng khách trong kết nối TLS. Ngược lại với mật khẩu đăng nhập, xác thực chứng chỉ ứng dụng khách được chỉ định như là một phần của giao thức TLS. Nó hoạt động tương tự như cách máy khách xác thực máy chủ: Máy khách tạo cặp khóa riêng tư công khai và gửi khóa công khai tới một CA đáng tin cậy để ký. CA trả về chứng chỉ ứng dụng khách có thể được sử dụng để xác thực máy khách. Bây giờ, khách hàng có thể sử dụng cùng một chứng chỉ để xác thực cho các máy chủ khác nhau (nghĩa là bạn có thể sử dụng cùng một chứng chỉ cho PayPal và MyPonyForum mà không có rủi ro rằng nó có thể bị lạm dụng). Cách nó hoạt động là sau khi máy chủ đã gửi chứng chỉ của nó, nó yêu cầu khách hàng cung cấp một chứng chỉ. Sau đó, một số phép thuật khóa công khai xảy ra (nếu bạn muốn biết chi tiết đọc RFC 5246) và bây giờ máy khách biết nó giao tiếp với đúng máy chủ, máy chủ biết nó giao tiếp với đúng máy khách và cả hai đều có một số tài liệu quan trọng phổ biến để mã hóa và xác minh kết nối.
Tôi đã tạo một client-rest-api gọi một server-rest-api (một cách gọi bài). Ứng dụng khách-api của tôi sử dụng chứng chỉ do máy chủ-phần còn lại-api cấp. Tuy nhiên, client-rest-api của tôi chưa bao giờ phát hành bất kỳ chứng chỉ nào cho server-rest-api. Liệu nó có dưới một chiều-ssl hay hai chiều-ssl? Sự kiện mặc dù chỉ là một cuộc gọi một chiều từ máy khách đến máy chủ, tôi nghĩ rằng hai chiều-ssl của nó kể từ đây máy chủ-nghỉ-api xác nhận rằng khách hàng có giấy chứng nhận thích hợp do máy chủ cấp? –
@HimalayMajumdar: Nếu máy chủ của bạn có chứng chỉ được ký bởi CA hoặc nếu bạn đã mã hóa chứng chỉ đó vào máy khách của mình (ghim), thì có, đó vẫn là TLS thích hợp với xác thực chứng chỉ ứng dụng khách (bạn gọi nó là hai chiều-ssl). Yay :-).Tuy nhiên, nếu khách hàng của bạn tin tưởng chứng chỉ máy chủ của bạn một cách mù quáng, thì về mặt kỹ thuật vẫn là TLS với xác thực chứng chỉ ứng dụng khách, nhưng bởi vì máy khách không thể kiểm tra chứng chỉ máy chủ, nó không phải là hai chiều và trong hầu hết các trường hợp đó là một ý tưởng tồi. Đừng làm điều đó :-( – NEOatNHNG
Thông thường khi tôi viết Java client gọi một dịch vụ kích hoạt https (https đã được ký tự), máy khách thường không thành công vì nó không tin tưởng chứng chỉ theo mặc định.Trong trường hợp máy khách java hiện tại của tôi, tôi chỉ cần nhập khẩu các certs do máy chủ vào classpath của tôi cho máy chủ để tin tưởng khách hàng của tôi, tôi đoán bằng cách nhập certs ngay cả khách hàng của tôi tự động tin tưởng máy chủ. –
Trong hai cách ssl máy khách yêu cầu máy chủ chứng chỉ kỹ thuật số và máy chủ yêu cầu tương tự từ máy khách. Nó được bảo mật hơn vì nó là cả hai cách, mặc dù hơi chậm. Nói chung chúng tôi không làm theo nó như là máy chủ không quan tâm về danh tính của khách hàng, nhưng một khách hàng cần phải chắc chắn về tính toàn vẹn của máy chủ nó đang kết nối đến.
+1 để có giải thích tốt và không trả lời google); – Dexters
bạn nên thay thế 'đã tạo' bằng 'đã ký' để giữ cho số này có liên quan – CharlieS
@CharlieS "* Hãy liên quan *" ... Bạn có ý là không liên quan khi sử dụng "tạo ra" (từ ngữ phù hợp với câu hỏi) ;-)? "Phát hành" có thể là một từ tốt hơn thực sự. – Bruno