Thuật toán trao đổi khóa Diffie-Hellman có thể được sử dụng để mã hóa giao tiếp client-server trên trang web thay cho SSL không? Nếu có thể, những nhược điểm (tức là tại sao tiêu chuẩn sử dụng SSL yêu cầu cơ quan cấp chứng chỉ)? Sự hiểu biết của tôi là Diffie-Hellman có thể được sử dụng để bí mật thiết lập một khóa chia sẻ mà sau đó có thể được sử dụng để mã hóa bất kỳ giao tiếp nào khác.Diffie-Hellman thay cho SSL?
Thực ra Diffie-Hellman là một phần của SSL. Nhưng một phần không thay thế người khác.
Từ here SSL Diffie-Helman được sử dụng cho:
này một trao đổi khóa Diffie-Hellman trong mà chứng chỉ của máy chủ chứa các công thông số Diffie-Hellman chữ ký của cơ quan chứng nhận (CA). Tức là, giấy chứng nhận khóa công khai chứa các thông số khóa công khai Diffie-Hellman. Khách hàng cung cấp các thông số khóa công khai của Diffie-Hellman trong giấy chứng nhận , nếu cần xác thực ứng dụng hoặc trong thông báo trao đổi khóa . Phương pháp này dẫn đến một khóa bí mật cố định giữa hai đồng nghiệp, dựa trên tính toán Diffie-Hellman bằng cách sử dụng các khóa công khai cố định .
Cả hai không thực sự so sánh được. DH là một thuật toán trao đổi khóa, không có gì nhiều hơn và không có gì ít hơn. SSL cố gắng thiết lập rằng máy chủ bạn đang kết nối thực sự là người mà nó nói. Để làm điều đó, nó sử dụng một chứng chỉ có thể được truy tìm lại cho ai đó bạn (được cho là có khả năng) tin cậy.
DH, tự nó, chỉ ngăn người khác đọc dữ liệu được truyền. SSL được thiết kế để thiết lập nhiều hơn đáng kể (nhưng có thể sử dụng DH để ngăn người khác đọc luồng).
Chỉ cần cho một ví dụ rõ ràng, bằng cách sử dụng DH (tự nó) một người đàn ông trong cuộc tấn công giữa là khá đơn giản. Nếu tôi có thể giúp bạn kết nối với máy chủ của tôi thay vì máy chủ mà bạn định sử dụng, tôi có thể sử dụng DH để thiết lập phiên "an toàn" với bạn. Sau đó tôi kết nối với máy chủ bạn dự định ban đầu. Mỗi gói tôi nhận được từ bạn, tôi giải mã, mã hóa lại bằng khóa mà tôi đã sử dụng để kết nối với máy chủ đó và gửi đến máy chủ đó. Tôi làm tương tự với tất cả các gói phản hồi của nó. Với bạn, mọi thứ có vẻ như nó đến trực tiếp từ máy chủ gốc và giao dịch mua bạn đã thực hiện (ví dụ) hoạt động như bình thường. Điều duy nhất thay đổi là tôi cũng lưu trữ số thẻ tín dụng của bạn và khi bạn cố gắng đổ đầy nhiên liệu vào ngày hôm sau, khoản phí bị từ chối, bởi vì trong thời gian chờ đợi, tôi đã chi hết tất cả tín dụng của bạn.
Xác thực trong SSL ít nhất là nhằm ngăn chặn điều đó xảy ra. Nếu trình duyệt của bạn đã cố gắng kết nối với (ví dụ) www.amazon.com, nó sẽ cảnh báo bạn nếu chứng chỉ SSL của tôi không xác định rằng nó đã được cấp cho www.amazon.com - và CA không nên phát hành chứng chỉ như vậy cho bất kỳ ai nhưng Amazon.
Chỉnh sửa: Đọc lại điều này, tôi nên thêm một điểm nữa: DH, tự nó, thậm chí không thực sự đảm bảo hầu hết những gì tôi đã nói ở trên. Bởi chính nó, DH chỉ là một cách để trao đổi một khóa (hoặc, có lẽ nó có thể được phrased là "trao đổi thông tin cần thiết cho cả hai bên để tạo ra các phím giống nhau, mà không bao giờ trao đổi chính nó trong rõ ràng"). Sau khi cả hai bên có khóa, họ có thể (và có lẽ sẽ) sử dụng nó để mã hóa/giải mã dữ liệu - nhưng mã hóa đó thực sự tách biệt với chính bản thân DH.
Bạn có thể sử dụng thỏa thuận khóa Diffie-Hellman ẩn danh với SSL. Điều này cung cấp quyền riêng tư trên kênh nhưng không có xác thực.
Tất nhiên, không có xác thực, bạn thực sự không thể có quyền riêng tư, vì kênh riêng tư của bạn có thể được kết nối với "người ở giữa". Đó là lý do tại sao các bộ mã hóa DH ẩn danh không được khuyến khích.
Nếu thiếu một chứng chỉ được ngăn cản bạn từ việc sử dụng SSL nơi nó thực sự cần thiết, có được một hình miễn phí từ startcom.org.
+1 - Liên kết gọn gàng, tôi đã tạo các chứng chỉ riêng cho máy chủ cá nhân của mình ... Tôi không nhận ra có các chứng chỉ miễn phí sử dụng CA được tích hợp sẵn trong trình duyệt để khách truy cập không phải thêm một ngoại lệ –
Tôi không nghĩ rằng IE hỗ trợ họ, thật không may. Gần đây tôi chưa xem xét nên tôi không chắc liệu đó có phải là trường hợp không. – erickson
Trên thực tế, kiểm tra nhanh trên startcom.org cho thấy rằng họ hỗ trợ Internet explorer. – cmaduro
Trao đổi khóa Diffie-Hellman là chỉ cho keyexchange. Nó không cung cấp cho bạn xác thực (bạn đang nói chuyện với ai), bạn cần chứng chỉ và PKI cho điều đó.
Vì vậy, có bạn có thể thực hiện mã hóa, nhưng bạn không biết bạn đang nói chuyện với ai
Trao đổi khóa DH không thể tự mã hóa. Nó được sử dụng để thiết lập khóa phiên, nhưng không được sử dụng để mã hóa. Vì vậy, ở cấp độ này, câu hỏi được đưa ra sai hoặc tiết lộ thiếu chính xác hoặc thiếu hiểu biết (tôi nghi ngờ độ chính xác là vấn đề lần này).
Câu hỏi đặt ra là:
Như đã được chỉ ra, SSL sử dụng trao đổi khóa DH để thiết lập khóa phiên. Tuy nhiên, nó cũng đảm bảo rằng chương trình ở đầu bên kia là một người mà bạn tin tưởng (trực tiếp hoặc gián tiếp). Nếu bạn không cần phải lo lắng về việc liệu người kia có đáng tin cậy không, bạn chỉ có thể sử dụng trao đổi khóa DH đơn giản và sau đó gửi dữ liệu được mã hóa mà không cần chứng chỉ. Nhưng bạn sẽ không chắc chắn bạn đang nói chuyện với ai trừ khi bạn xác nhận điều đó - và các chứng chỉ được sử dụng bởi SSL, vv giúp với việc xác thực đó.
Vì vậy, tôi đoán không có cách nào để tránh sử dụng PKI. Tôi đã chỉ tự hỏi về sự tò mò nếu có một cách cho 2 bên (bất kể phí trên thuật toán) để thiết lập một liên kết được mã hóa một cách đáng tin cậy mà không sử dụng một bên thứ ba. – kmnan
Về lý thuyết số. Bởi vì không sử dụng bất kỳ bên thứ ba nào, bạn không thể chắc chắn rằng bạn đang thiết lập liên kết được mã hóa với mục tiêu mong muốn của mình. – alexkr
Chắc chắn, có. Ví dụ: nếu hai bên trao đổi khóa công khai của họ trong một bên ký kết khóa, thì họ không cần bất kỳ bên thứ ba nào để thiết lập kết nối an toàn. – Accipitridae