it-swarm-vi.com

Những lỗ hổng nào có thể được gây ra bởi chứng chỉ SSL ký tự đại diện?

Trong một nhận xét về câu trả lời này , AviD nói:

"Có rất nhiều vấn đề bảo mật với các chứng nhận SSL ký tự đại diện."

Vì vậy, những vấn đề là gì? Tôi hiểu rằng cùng một khóa riêng đang được sử dụng trong nhiều ngữ cảnh, nhưng do tôi có thể Lưu trữ tất cả các ứng dụng của mình dưới cùng một tên Máy chủ, tôi không thấy đây là vấn đề 'mới' được giới thiệu bởi chứng chỉ ký tự đại diện.

46
user185

"Chứng chỉ ký tự đại diện" là chứng chỉ chứa tên máy chủ có thể, tên chứa ký tự "*". Chi tiết có trong RFC 2818, phần 3.1 . Dòng dưới cùng: khi chứng chỉ máy chủ chứa *.example.com, Nó sẽ được chấp nhận bởi các máy khách làm chứng chỉ hợp lệ cho bất kỳ máy chủ nào có = tên rõ ràng khớp với tên đó.

Trong kinh doanh chứng nhận cho các trang web, có bốn tác nhân chính:

  • Máy chủ SSL chính nó.
  • Nhà cung cấp trình duyệt Web mà khách hàng sẽ sử dụng.
  • Người dùng con người, người kiểm soát ở một mức độ nào đó trình duyệt máy khách sẽ làm gì.
  • CA đã cấp chứng chỉ cho máy chủ.

Chứng chỉ ký tự đại diện không ngụ ý các lỗ hổng bổ sung cho máy chủ SSL; thật vậy, máy chủ SSL không quan tâm đến việc xem xét chứng chỉ của chính nó. Chứng chỉ đó là vì lợi ích của khách hàng, để thuyết phục họ rằng khóa công khai có trong chứng chỉ thực sự là khóa chung của máy chủ SSL chính hãng. Máy chủ SSL biết cặp khóa công khai/riêng của nó và không cần phải bị thuyết phục về nó.

Người dùng không biết khóa công khai là gì. Những gì anh ta nhìn thấy là một biểu tượng ổ khóa và quan trọng hơn là tên máy chủ dự định : đó là tên ở bên phải của "https://" và trước "/" tiếp theo. Trình duyệt web là được cho là để xử lý các chi tiết kỹ thuật xác minh rằng tên đó là đúng, tức là xác thực chứng chỉ máy chủ và xác minh rằng tên khớp với tên được ghi trong chứng chỉ đã nói. Nếu trình duyệt không thực hiện công việc này, thì nó sẽ bị xem là cẩu thả và không đảm nhận vai trò của nó, điều này có thể gây hậu quả thương mại nghiêm trọng, thậm chí có thể hợp pháp. Tương tự, CA bị ràng buộc theo hợp đồng tuân theo các quy trình được xác định để xác định chủ sở hữu máy chủ SSL để chứng chỉ giả sẽ khó lấy được cho kẻ tấn công (hợp đồng nằm giữa CA và über-CA của nó, theo cách đệ quy, cho đến CA gốc bị ràng buộc bởi một hiệp ước với HĐH hoặc nhà cung cấp trình duyệt, người đã chấp nhận đưa khóa CA gốc vào HĐH hoặc trình duyệt trong các điều kiện xác định).

Điều này có nghĩa là, trình duyệt [~ # ~] ca [~ # ~] phải, trong thực tế, nuông chiều người dùng thông qua quá trình xác minh. Chúng ít nhiều theo nghĩa vụ (theo luật pháp hoặc thậm chí nghiêm ngặt hơn bởi các cân nhắc kinh doanh) để ngăn chặn người dùng bị lừa đảo thông qua các trang web giả mạo có vẻ hợp pháp. Ranh giới giữa công việc của người dùng và công việc trình duyệt/CA không được xác định rõ ràng và đã di chuyển trong lịch sử. Trong Days of Yore, ý tôi là mười năm trước hoặc lâu hơn, các trình duyệt chỉ in ra URL thô và tùy thuộc vào người dùng tìm thấy tên máy chủ trong đó. Điều này dẫn đến các nhà điều hành trang web giả mạo (tức là "các trang lừa đảo") để sử dụng URL có giá trị về mặt kỹ thuật, nhưng gây hiểu lầm, như thế này:

https://www.Paypal.com:[email protected]/confirm.html

Vì người dùng của con người, tốt, con người, và hầu hết trong số họ đọc từ trái sang phải (hầu hết các mục tiêu lừa đảo giàu có và cả tin vẫn ở các nước phương Tây), họ sẽ bắt đầu ở bên trái, xem www.Paypal.com, Dừng lại ở dấu hai chấm ("quá kỹ thuật") và bị lừa đảo.

Trong phản ứng, các nhà cung cấp trình duyệt đã thừa nhận rằng khả năng phân tích cú pháp URL của người dùng không tốt như ban đầu, và do đó các trình duyệt gần đây làm nổi bật phần tên miền. Trong trường hợp trên, đây sẽ là xcvhjvb.com Và chắc chắn không có gì có Paypal.com Trong đó. Bây giờ đến phần mà chứng chỉ ký tự đại diện vào trò chơi. Nếu chủ sở hữu của xcvhjvb.com Mua chứng chỉ ký tự đại diện có chứa "*.xcvhjvb.com", Thì anh ta có thể thiết lập trang web lừa đảo có tên:

https://Paypal-payment-interface-login-session.xcvhjvb.com/confirm.html

sẽ được trình duyệt chấp nhận (phù hợp với tên ký tự đại diện) và vẫn có khả năng bắt người dùng không chính thức (và có nhiều ...). Tên này could đã bị kẻ tấn công mua mà không dùng đến ký tự đại diện, nhưng sau đó nhân viên CA sẽ thấy tên đó với nỗ lực lừa đảo rõ ràng (CA tốt do xác thực của con người đối với mọi yêu cầu chứng nhận hoặc ít nhất là đưa ra cảnh báo cho các tên rất dài và/hoặc chứa tên ngân hàng đã biết trong đó).

Do đó, chứng chỉ ký tự đại diện làm giảm hiệu quả của các biện pháp ngăn chặn gian lận ở phía CA . Đây giống như một chữ ký trống từ CA. Nếu các nỗ lực lừa đảo dựa trên ký tự đại diện trở nên phổ biến hơn, người ta có thể mong đợi rằng một hoặc một số biện pháp sau đây sẽ xuất hiện:

  • Các trình duyệt chỉ làm nổi bật các phần của tên miền khớp với non-wildcard các phần tử trong chứng chỉ.
  • CA yêu cầu giấy tờ và hợp đồng nặng hơn đối với chứng chỉ ký tự đại diện (và những thứ này sẽ đắt hơn).
  • Các trình duyệt hủy kích hoạt hỗ trợ cho chứng chỉ ký tự đại diện hoàn toàn.

Tôi thực sự mong đợi cả ba biện pháp sẽ được áp dụng trong vòng những năm tới. Tôi có thể hoàn toàn sai về nó (đó là vấn đề với việc dự đoán tương lai) nhưng đây vẫn là cảm giác ruột của tôi.


Nitpickingly, chúng tôi cũng có thể chỉ ra rằng chứng chỉ ký tự đại diện rất hữu ích để chia sẻ cùng một cặp khóa giữa các máy chủ khác nhau name, điều này có thể xảy ra rằng khóa riêng sẽ được chia sẻ giữa các máy chủ khác nhau machines. Du lịch khóa riêng là một rủi ro bảo mật theo cách riêng của họ; Càng nhiều chìa khóa riêng lang thang xung quanh, nó càng ít "riêng tư".

35
Thomas Pornin

Việc phát tán cùng một khóa riêng trên nhiều máy chủ cung cấp dịch vụ khác nhau là một thực tế xấu: Bất kỳ vấn đề bảo mật nào được khai thác trong bất kỳ dịch vụ nào cũng sẽ tiết lộ khóa riêng được sử dụng cho mọi thứ.

Nhưng thông thường sử dụng chứng chỉ ký tự đại diện để cô lập nội dung web do người dùng đóng góp trong các tên miền phụ cụ thể của người dùng để tận dụng chính sách Xuất xứ tương tự. Cách tiếp cận tương tự thường được sử dụng để kết xuất các portlet không tin cậy. Đó là một phần của Xã hội mở "tiêu chuẩn".

Tại nơi làm việc của tôi, chúng tôi phát triển một phần mềm chứa triển khai xã hội mở và sử dụng cài đặt ký tự đại diện. Cài đặt của khách hàng đã được kiểm tra thâm nhập. Thiết lập ký tự đại diện không bị chỉ trích.

18
Hendrik Brummermann

Cuối cùng, nhiều lỗ hổng được ghi nhận trong các câu trả lời này đến từ các mức độ tin cậy lẫn lộn. Nhưng nếu bạn hiểu làm thế nào các ký tự đại diện hoạt động, bạn có thể giảm thiểu các lỗ hổng này cho các trường hợp sử dụng cụ thể. Tôi nghĩ rằng việc giải thích điều này chi tiết hơn sẽ cải thiện tính hữu ích của câu hỏi này và câu trả lời của nó.

Trừ khi tất cả các hệ thống trong miền của bạn có cùng mức độ tin cậy, sử dụng chứng chỉ ký tự đại diện để bao trùm tất cả các hệ thống dưới sự kiểm soát của bạn là một ý tưởng tồi. Nhưng bạn có thể sử dụng tên miền phụ DNS làm công cụ phân đoạn. Như Hendrik đã nói, vì các ký tự đại diện không đi qua các tên miền phụ, bạn có thể giới hạn chứng chỉ ký tự đại diện cho một không gian tên cụ thể. Ví dụ: nếu bạn có trang trại CDN, bạn có thể ký tự đại diện chỉ *.cdn.example.com. Điều này giữ máy chủ trong example.com chính nó (như www.example.com) riêng biệt và bạn có thể cấp chứng chỉ riêng cho www.example.com.

Như AviD đã đề cập từ OWASP: máy trạm nội bộ, hệ thống phát triển, vv thuộc về mức độ tin cậy thấp hơn. Tuy nhiên, các máy chủ như thế này phải ở trong không gian tên miền nội bộ của riêng chúng (như prv.example.com). Vì các ký tự đại diện không đi qua các tên miền phụ, nên *.example.com cert không thể được áp dụng cho prv.example.com máy chủ lưu trữ. (Điều này sẽ tách biệt các thuộc tính công cộng và riêng tư, nhưng rõ ràng không tách biệt các thuộc tính riêng tư với nhau. Các ký tự đại diện phụ khác có thể được sử dụng, được ánh xạ tới các mức độ tin cậy phù hợp).

Trong khi bài viết trên eWeek này lưu ý rằng khóa riêng có thể được chia sẻ trên nhiều máy chủ, phản hồi SSLShopper này nói rằng một số nhà phát hành (như DigiCert) cho phép bạn tạo các khóa riêng cho từng Máy chủ lưu trữ ký tự đại diện. Điều này không làm giảm một số tính hữu dụng của các ký tự đại diện, nhưng chắc chắn giảm thiểu vấn đề khóa chung-riêng và có thể hữu ích trong một số trường hợp. Mặt khác, bài viết Entrust nàywhitepaper PDF mà nó tham chiế thảo luận về các cách thực hành tốt nhất để quản lý khóa riêng khi được sử dụng với các ký tự đại diện.

Cuối cùng, dùng đến sự tranh luận của chính quyền ... nếu Google đang sử dụng các ký tự đại diện cho một số thuộc tính của họ , chúng không được phổ biến xấu:

Qualys SSL Labs screenshot for youtube.com cert

:-)

9
Royce Williams

Lý tưởng nhất là danh sách các dịch vụ mà chứng chỉ/khóa có thể được sử dụng để mạo danh phải giống với danh sách các dịch vụ mà chứng chỉ/khóa dự định sẽ được sử dụng.

Hãy nói rằng bạn có một ví dụ tên miền.com. Bạn thiết lập nhiều tên máy chủ khác nhau trong tên miền đó www.example.com catpictures.example.com users.example.com. Tất cả được lưu trữ trên cùng một máy chủ để bạn có được một chứng chỉ để bao gồm tất cả.

Bây giờ, giả sử bạn thiết lập safe.example.com trên một máy chủ được bảo mật cao hơn. Hãy nói rằng bạn có được một chứng chỉ riêng cho máy chủ đó.

Bây giờ hãy xem xét những gì xảy ra nếu khóa riêng tương ứng với chứng chỉ trên máy chủ đầu tiên bị đánh cắp.

Nếu đó là chứng chỉ cho * .example.com (chứng chỉ ký tự đại diện) thì kẻ tấn công có thể sử dụng nó để mạo danh safe.example.com

Nếu đó là một chứng chỉ cho www.example.com catpictures.example.com và users.example.com thì những kẻ tấn công không thể sử dụng nó để mạo danh safe.example.com

4
Peter Green