Lưu ý: Tôi đã viết câu trả lời ban đầu của mình rất vội vàng, nhưng kể từ đó, nó đã biến thành một câu hỏi / câu trả lời khá phổ biến, vì vậy tôi đã mở rộng nó một chút và làm cho nó chính xác hơn.
Khả năng của TLS
"SSL" là tên thường được sử dụng để chỉ giao thức này, nhưng SSL đặc biệt đề cập đến giao thức độc quyền được thiết kế bởi Netscape vào giữa những năm 90. "TLS" là một tiêu chuẩn IETF dựa trên SSL, vì vậy tôi sẽ sử dụng TLS trong câu trả lời của mình. Ngày nay, tỷ lệ cược là gần như tất cả các kết nối an toàn của bạn trên web thực sự sử dụng TLS, không phải SSL.
TLS có một số khả năng:
- Mã hóa dữ liệu lớp ứng dụng của bạn. (Trong trường hợp của bạn, giao thức lớp ứng dụng là HTTP.)
- Xác thực máy chủ cho khách hàng.
- Xác thực ứng dụng khách đến máy chủ.
# 1 và # 2 là rất phổ biến. # 3 là ít phổ biến hơn. Bạn dường như đang tập trung vào # 2, vì vậy tôi sẽ giải thích phần đó.
Xác thực
Một máy chủ tự xác thực cho khách hàng bằng chứng chỉ. Chứng chỉ là một kho dữ liệu [1] chứa thông tin về trang web:
- Tên miền
- Khóa công khai
- Công ty sở hữu nó
- Khi nó được ban hành
- Khi nó hết hạn
- Ai đã ban hành nó
- Vân vân.
Bạn có thể đạt được tính bảo mật (số 1 ở trên) bằng cách sử dụng khóa chung có trong chứng chỉ để mã hóa các tin nhắn chỉ có thể được giải mã bằng khóa riêng tương ứng, được lưu trữ an toàn trên máy chủ đó. [2] Hãy gọi cặp khóa này là KP1, để sau này chúng ta sẽ không bị lẫn lộn. Bạn cũng có thể xác minh rằng tên miền trên chứng chỉ phù hợp với trang web bạn đang truy cập (# 2 ở trên).
Nhưng điều gì sẽ xảy ra nếu một đối thủ có thể sửa đổi các gói được gửi đến và từ máy chủ, và nếu đối thủ đó sửa đổi chứng chỉ mà bạn được trình bày và chèn khóa công khai của riêng họ hoặc thay đổi bất kỳ chi tiết quan trọng nào khác thì sao? Nếu điều đó xảy ra, đối thủ có thể chặn và sửa đổi bất kỳ tin nhắn nào bạn nghĩ đã được mã hóa an toàn.
Để ngăn chặn cuộc tấn công này, chứng chỉ được ký mã hóa bằng khóa riêng của người khác theo cách mà chữ ký có thể được xác minh bởi bất kỳ ai có khóa chung tương ứng. Hãy gọi cặp khóa này là KP2, để làm rõ rằng đây không phải là các khóa giống nhau mà máy chủ đang sử dụng.
Cơ quan cấp chứng chỉ
Vậy ai đã tạo ra KP2? Ai đã ký giấy chứng nhận?
Đơn giản hóa một chút, một cơ quan chứng nhận tạo KP2 và họ bán dịch vụ sử dụng khóa riêng của họ để ký chứng chỉ cho các tổ chức khác. Ví dụ: tôi tạo chứng chỉ và tôi trả cho một công ty như Verisign để ký bằng khóa riêng của họ. [3] Vì không ai ngoài Verisign có quyền truy cập vào khóa riêng này, không ai trong chúng tôi có thể giả mạo chữ ký này.
Và cá nhân tôi sẽ nhận được khóa công khai trong KP2 như thế nào để xác minh chữ ký đó?
Vâng, chúng ta đã thấy rằng một chứng chỉ có thể giữ khóa công khai - và các nhà khoa học máy tính thích đệ quy - vậy tại sao không đặt khóa công khai KP2 vào một chứng chỉ và phân phối theo cách đó? Điều này thoạt nghe có vẻ hơi điên rồ, nhưng thực tế đó chính xác là cách nó hoạt động. Tiếp tục với ví dụ Verisign, Verisign tạo ra một chứng chỉ bao gồm thông tin về họ là ai, loại điều họ được phép ký (các chứng chỉ khác) và khóa chung của họ.
Bây giờ nếu tôi có một bản sao của chứng chỉ Verisign đó, tôi có thể sử dụng nó để xác thực chữ ký trên chứng chỉ máy chủ cho trang web tôi muốn truy cập. Dễ thôi phải không?!
Chà, không nhanh như vậy. Tôi phải lấy chứng chỉ Verisign từ đâu đó . Điều gì xảy ra nếu ai đó giả mạo chứng chỉ Verisign và đặt khóa công khai của riêng họ vào đó? Sau đó, họ có thể giả mạo chữ ký trên chứng chỉ của máy chủ và chúng tôi quay lại ngay nơi chúng tôi bắt đầu: một cuộc tấn công trung gian.
Chuỗi chứng chỉ
Tiếp tục suy nghĩ đệ quy, tất nhiên chúng tôi có thể giới thiệu chứng chỉ thứ ba và cặp khóa thứ ba (KP3) và sử dụng chứng chỉ đó để ký chứng nhận Verisign. Chúng tôi gọi đây là chuỗi chứng chỉ: mỗi chứng chỉ trong chuỗi được sử dụng để xác minh chứng chỉ tiếp theo. Hy vọng rằng bạn có thể thấy rằng phương pháp đệ quy này chỉ là rùa / chứng chỉ. Nó dừng ở đâu?
Vì chúng tôi không thể tạo số lượng chứng chỉ vô hạn, chuỗi chứng chỉ rõ ràng phải dừng ở đâu đó và điều đó được thực hiện bằng cách bao gồm chứng chỉ trong chuỗi tự ký .
Tôi sẽ dừng lại một chút trong khi bạn nhặt những mảnh vật chất từ đầu phát nổ. Tự ký?!
Có, ở cuối chuỗi chứng chỉ (còn gọi là "root"), sẽ có một chứng chỉ sử dụng khóa riêng để tự ký. Điều này giúp loại bỏ vấn đề đệ quy vô hạn, nhưng nó không khắc phục được vấn đề xác thực. Bất cứ ai cũng có thể tạo chứng chỉ tự ký có ghi bất cứ điều gì trên đó, giống như tôi có thể tạo bằng tốt nghiệp Princeton giả nói rằng tôi học ba chuyên ngành chính trị, vật lý lý thuyết, và áp dụng đá mông và sau đó ký tên của mình ở phía dưới.
Giải pháp [hơi khó chịu] cho vấn đề này chỉ là chọn một số bộ chứng chỉ tự ký mà bạn tin tưởng rõ ràng. Ví dụ: tôi có thể nói: "Tôi tin tưởng vào chứng chỉ tự ký Verisign này."
Với sự tin tưởng rõ ràng đó, giờ tôi có thể xác nhận toàn bộ chuỗi chứng chỉ. Cho dù có bao nhiêu chứng chỉ trong chuỗi, tôi có thể xác nhận từng chữ ký cho đến tận gốc. Khi tôi đến root, tôi có thể kiểm tra xem chứng chỉ gốc đó có phải là chứng chỉ mà tôi tin tưởng rõ ràng hay không. Nếu vậy, sau đó tôi có thể tin tưởng toàn bộ chuỗi.
Trao niềm tin
Xác thực trong TLS sử dụng một hệ thống tin cậy được trao . Nếu tôi muốn thuê một thợ cơ khí tự động, tôi có thể không tin bất kỳ thợ máy ngẫu nhiên nào mà tôi tìm thấy. Nhưng có lẽ bạn tôi chứng nhận cho một thợ máy cụ thể. Vì tôi tin tưởng bạn mình, nên tôi có thể tin người thợ đó.
Khi bạn mua một máy tính hoặc tải xuống một trình duyệt, nó đi kèm với một vài trăm chứng chỉ gốc mà nó tin tưởng rõ ràng. [4] Các công ty sở hữu và vận hành các chứng chỉ đó có thể trao niềm tin đó cho các tổ chức khác bằng cách ký chứng chỉ của họ.
Đây là một hệ thống hoàn hảo. Đôi khi CA có thể cấp chứng chỉ sai. Trong những trường hợp đó, chứng chỉ có thể cần phải thu hồi. Việc thu hồi là khó khăn vì chứng chỉ được cấp sẽ luôn luôn đúng về mặt mật mã; một giao thức ngoài băng là cần thiết để tìm ra những chứng chỉ hợp lệ trước đó đã bị thu hồi. Trong thực tế, một số giao thức này không an toàn và nhiều trình duyệt không kiểm tra chúng.
Đôi khi toàn bộ CA bị xâm phạm. Ví dụ: nếu bạn đột nhập vào Verisign và đánh cắp khóa ký gốc của họ, thì bạn có thể giả mạo bất kỳ chứng chỉ nào trên thế giới. Lưu ý rằng điều này không chỉ ảnh hưởng đến khách hàng của Verisign: ngay cả khi chứng chỉ của tôi được ký bởi Thawte (đối thủ cạnh tranh với Verisign), điều đó không thành vấn đề. Chứng chỉ của tôi vẫn có thể được giả mạo bằng cách sử dụng khóa ký bị xâm phạm từ Verisign.
Đây không chỉ là lý thuyết. Nó đã xảy ra trong tự nhiên. DigiNotar đã bị hack nổi tiếng và sau đó bị phá sản. Comodo cũng bị hack , nhưng không hiểu sao họ vẫn duy trì hoạt động cho đến ngày nay.
Ngay cả khi CA không bị xâm phạm trực tiếp, vẫn có những mối đe dọa khác trong hệ thống này. Ví dụ, một chính phủ sử dụng sự ép buộc pháp lý để buộc CA ký giấy chứng nhận giả mạo. Chủ lao động của bạn có thể cài đặt chứng chỉ CA của riêng họ trên máy tính nhân viên của bạn. Trong các trường hợp khác nhau này, lưu lượng truy cập mà bạn mong đợi là "an toàn" thực sự hoàn toàn hiển thị / có thể sửa đổi đối với tổ chức kiểm soát chứng chỉ đó.
Một số thay thế đã được đề xuất, bao gồm Hội tụ , TACK và Dane .
Chú thích
[1] Dữ liệu chứng chỉ TLS được định dạng theo tiêu chuẩn X.509 . X.509 dựa trên ASN.1 ("Ký hiệu cú pháp trừu tượng số 1"), có nghĩa là nó không phải là định dạng dữ liệu nhị phân. Do đó, X.509 phải được mã hóa thành định dạng nhị phân. DER và PEM là hai bảng mã phổ biến nhất mà tôi biết.
[2] Trong thực tế, giao thức thực sự chuyển sang một mật mã đối xứng, nhưng đó là một chi tiết không liên quan đến câu hỏi của bạn.
[3] Có thể, CA thực sự xác nhận bạn là ai trước khi ký chứng chỉ của bạn. Nếu họ không làm điều đó, thì tôi có thể tạo chứng chỉ cho google.com và yêu cầu CA ký tên. Với chứng nhận đó, tôi có thể kết nối bất kỳ kết nối "an toàn" nào với google.com. Do đó, bước xác nhận là một yếu tố rất quan trọng trong hoạt động của CA. Thật không may, không rõ ràng quá trình xác nhận này nghiêm ngặt như thế nào tại hàng trăm CA trên toàn thế giới.
[4] Xem danh sách CA đáng tin cậy của Mozilla .
