it-swarm-vi.com

Làm thế nào khả thi cho một CA bị hack? Những chứng chỉ gốc đáng tin cậy nào tôi nên xóa?

Câu hỏi này đã được sửa đổi & làm rõ đáng kể từ phiên bản gốc.

Nếu chúng tôi xem xét từng chứng chỉ tin cậy trong cửa hàng Root đáng tin cậy của tôi, tôi nên tin tưởng chúng bao nhiêu?

Những yếu tố nào cần được xem xét khi tôi đánh giá sự tin cậy của từng Root CA để loại bỏ tiềm năng khỏi cửa hàng địa phương của tôi?

Thêm thông tin:
[.___ Do đó, tất cả các CA đều xác nhận nghiêm ngặt người yêu cầu của một yêu cầu chứng chỉ SSL nhất định để đảm bảo tính toàn vẹn của chuỗi CS của họ.

Tuy nhiên, một phần lớn của quy trình xác minh CA này phải chịu sự can thiệp của con người và cung cấp cơ hội để cấp chứng nhận cho bên sai. Điều này có thể được thực hiện do lỗi của nhà điều hành CA, yêu cầu của chính phủ hoặc có thể là sự ép buộc (hối lộ) của một nhà điều hành CA.

Tôi muốn tìm hiểu thêm về những CA mặc định nào có nhiều khả năng cấp chứng chỉ cho bên sai. Tôi dự định sử dụng thông tin này để khuyên người dùng xóa CA đó khỏi Cửa hàng Chứng chỉ đáng tin cậy của họ

Ví dụ:
[.__.] Giả sử chính phủ kiểm soát một CA cụ thể muốn thừa nhận danh tính của Microsoft.com và yêu cầu một ngoại lệ đối với quy trình xác minh của CA. Chính phủ đó sau đó cũng yêu cầu giữ bí mật ngoại lệ này. Cặp khóa được tạo sau đó sẽ được sử dụng trong một cuộc tấn công MITM.

Ủy thác mặc định của Windows Azure

Windows Azure hỗ trợ 275 CA như thể hiện trong liên kết sa . Tùy thuộc vào việc sử dụng CA cụ thể, một số CA đó có thể làm tăng diện tích bề mặt của một cuộc tấn công cụ thể. Trong thực tế, điều này có thể được yêu cầu về mặt kỹ thuật để làm cho một số ứng dụng hoạt động chính xác.

Ủy thác mặc định của Amazon

(không khả dụng) Vui lòng chia sẻ liên kết đến danh sách CA mặc định của Amazon, Google và VMWare nếu bạn gặp chúng.

Mozilla

A danh sách tất cả các chứng chỉ và báo cáo kiểm toán có sẵn.

Apple iOS

Danh sách tất cả chứng chỉ gốc của iPhone như được đề cập trong # WWDC2017. Video này

84
goodguys_activate

Cập nhật 5 Vấn đề gốc (heh) với mô hình CA là trong thực tế chung, bất kỳ CA nào cũng có thể phát hành certs cho bất kỳ miền nào, vì vậy bạn Tôi dễ bị tổn thương bởi liên kết yếu nhất. Đối với những người bạn có thể tin tưởng, tôi nghi ngờ rằng danh sách này rất dài, vì các cổ phần rất cao và bảo mật rất khó. Tôi đề nghị bài viết của Christopher Soghoian về chủ đề này, làm rõ các cách tiếp cận khác nhau rằng các chính phủ trên thế giới đã từng truy cập vào dữ liệu người dùng cá nhân - cho dù bằng cách yêu cầu trực tiếp từ các công ty vận hành dịch vụ đám mây, qua wiretap, hoặc ngày càng thông qua cưỡng chế hoặc hack CA: hoang tưởng nhẹ: Các lực lượng dẫn đầu để hack DigiNotar .

Ở đây tôi cung cấp một số chi tiết cụ thể và kết thúc bằng các liên kết đến một số bản sửa lỗi tiềm năng.

Vào năm 2009, Etaluat (60% thuộc sở hữu của chính phủ Các Tiểu vương quốc Ả Rập Thống nhất), đã tung ra một bản vá BlackBerry trông vô hại, chèn phần mềm gián điệp vào các thiết bị của RIM, cho phép theo dõi email, vì vậy nó khó có thể được coi là đáng tin cậy. Nhưng nó có trong rất nhiều danh sách CA đáng tin cậy: http: //arstechnica.com/business/news/2009/07/mobile-carrier-rolls-out-spyware-as-a-3g-update.ars

Cập nhật 1 Xem thêm một ví dụ về một cuộc tấn công thành công, được cho là của một người Iran có tên ComodoHacker , chống lại Comodo : Chứng chỉ SSL Rogue ("comodogate trường hợp") - Weblog F-Secure . F-Secure lưu ý rằng Mozilla bao gồm các chứng chỉ do CA tại Trung Quốc, Israel, Bermuda, Nam Phi, Estonia, Romania, Slovakia, Tây Ban Nha, Na Uy, Colombia, Pháp, Đài Loan, Anh, Hà Lan, Thổ Nhĩ Kỳ, Mỹ, Hồng Kông, Nhật Bản , Hungary, Đức và Thụy Sĩ.

Tunisia là một quốc gia khác điều hành một CA đáng tin cậy rộng rãi và cũng có tài liệu tốt về các hành động của chính phủ của họ để xâm phạm quyền riêng tư: Câu chuyện bên trong về cách Facebook phản ứng với Hacks Tunisia - Alexis Madrigal - Công nghệ - Đại Tây Dương

Mozilla lưu ý một thực tiễn đáng nghi ngờ khác cần chú ý: CA cho phép đối tác RA phát hành certs trực tiếp từ gốc, thay vì thông qua một trung gian: Vấn đề về chứng chỉ Comodo - Theo dõi tại Mozilla Security Blog .
[.__.] Xem thêm chi tiết, bao gồm suy đoán về yêu cầu trách nhiệm của một tin tặc người Iran đơn độc Trình duyệt web và Comodo tiết lộ Cuộc tấn công của Cơ quan chứng nhận thành công, có lẽ từ Iran | Tự do để Tinker

Cập nhật 3 : Một cuộc tấn công thành công khác dường như cũng của ComodoHacker là chống lại DigiNotar CA. Trang web của họ đã bị xâm phạm bắt đầu từ năm 2009, nhưng điều này không được chú ý cho đến sau khi DigiNotar cũng được người Iran sử dụng vào năm 2011 để ký chứng chỉ giả cho các trang web của Google, Yahoo!, Mozilla, WordPress và Dự án Tor. DigiNotar đã không tiết lộ kiến ​​thức về sự xâm nhập vào trang web của mình trong hơn một tháng. Xem thêm tại DigiNotar Hack nhấn mạnh những thất bại nghiêm trọng của Mô hình bảo mật web SSL của chúng tôi | Tự do đối với Tinker .

Tôi đoán rằng phạm vi dễ bị tổn thương của các CA khác nhau khá khác nhau, cũng như tiện ích của chúng. Vì vậy, tôi khuyên bạn nên tập trung lại chiến lược của mình. Khi bạn có thể thu hẹp nó vào các tài sản cụ thể mà bạn đang cố gắng bảo vệ, chỉ cần xóa tất cả các CA ngoại trừ những CA cần thiết để sử dụng các tài sản đó. Mặt khác, hãy xem xét loại bỏ các CA mà bạn đánh giá là dễ bị tổn thương nhất đối với những người quan tâm đến tài sản của bạn, hoặc ít phổ biến nhất, chỉ để giảm bề mặt tấn công. Nhưng chấp nhận thực tế là bạn sẽ vẫn dễ bị tấn công tinh vi ngay cả chống lại các CA phổ biến và cẩn thận nhất.

Cập nhật 2 : Có một bài viết tuyệt vời về việc sửa chữa cơ sở hạ tầng CA nguy hiểm của chúng tôi tại Freedom to Tinker: Xây dựng cơ sở hạ tầng CA tốt hơn

Nó nói về những đổi mới này:

Cập nhật 4 Một trong những bài đăng trên blog Bảo mật CNTT của chúng tôi vào tháng 8 năm 2011 cũng đề cập đến trường hợp chuyển sang DNSSEC: Dựa trên rủi ro Nhìn vào Khắc phục sự cố Cơ quan cấp chứng chỉ "Blog bảo mật trao đổi Stack

Cập nhật 6 Một số Cơ quan cấp chứng chỉ đã bị bắt vì vi phạm các quy tắc. Điều đó bao gồm cơ quan bảo mật không gian mạng của Pháp (ANSSI) và Trustwave, mỗi cơ quan được liên kết với việc giả mạo chứng chỉ kỹ thuật số .

Cập nhật 7 Một bộ "chứng chỉ bị sai lệch" khác, thông qua Kiểm soát viên của Cơ quan chứng nhận Ấn Độ (CCA Ấn Độ) năm 2014: Blog bảo mật trực tuyến của Google: Duy trì bảo mật chứng chỉ số

Xem thêm câu hỏi về Minh bạch chứng chỉ có vẻ như là một cách tiếp cận hữu ích để khám phá các chứng chỉ xấu và vi phạm chính sách trước đó.

64
nealmcb

Như Matt Blaze đã từng viết, CA bảo vệ bạn khỏi bất cứ ai mà họ không muốn lấy tiền. Điều đó sẽ cho bạn biết điều gì đó về việc các ưu đãi của CA nằm ở đâu và một số rủi ro tiềm ẩn trong sự sắp xếp.

38
D.W.

Tôi sợ rằng câu trả lời ngắn gọn cho câu hỏi này là không thể biết được, theo như tôi có thể thấy. Có một số lượng lớn CA mặc định được cài đặt trong hầu hết các trình duyệt phổ biến và việc đánh giá khả năng chúng "đáng tin cậy" như thế nào về việc cấp chứng chỉ cho chính phủ hoặc tổ chức khác là khó khăn.

Nếu một CA được biết đến là không đáng tin thì có khả năng họ sẽ bị xóa khỏi danh sách cài đặt mặc định của trình duyệt, (per @xce bên dưới, Diginotar là một ví dụ điển hình ở đây và cả Digicert)

Ngoài việc tổ chức cung cấp chứng chỉ một cách tự nguyện, có nguy cơ họ có thể cung cấp chứng chỉ mà không thực hiện kiểm tra bảo mật thích hợp cho người yêu cầu. Tại Defcon một vài năm trước, đã có một vài bài thuyết trình về chủ đề này để có thể nhận được chứng chỉ mà không cần sự cho phép.

Nếu đây là một mối quan tâm đáng kể, cách duy nhất tôi có thể nghĩ đến là tạo một danh sách trắng các CA mà bạn đã xem xét và cảm thấy thoải mái với bảo mật được cung cấp. Rõ ràng điều này sẽ không hoạt động để truy cập Internet nói chung vì có thể bạn sẽ loại bỏ các CA có vấn đề về các trang web mà bạn muốn sử dụng.

18
Rory McCune

2 ví dụ đi vào trung tâm của những gì bạn cần biết, nhưng không phải là những gì bạn hỏi rõ ràng:

  • Cách đây vài năm (2006, hoặc có thể là cuối năm 2005) đã xảy ra sự cố lừa đảo SSL được công bố rộng rãi - một trang web ngân hàng không có thật đã nhận được chứng nhận SSL hợp pháp (từ GeoTrust, tôi tin), vì đã viết sai chính tả của một ngân hàng khu vực. (Cập nhật: đã tìm thấy liên kết lịch sử này - địa chỉ là tên đầy đủ của ngân hàng thay vì từ viết tắt rút gọn). Kể từ đó, đã có nhiều trường hợp lừa đảo SSL khác .... Điểm là có thể lấy chứng chỉ mà không cần dùng đến "sự ép buộc".
  • Gần đây Stuxnet novella dựa vào, trong số các chiến thuật khác, chứng chỉ bị đánh cắp. Chúng được "mượn" từ các nhà sản xuất trình điều khiển bên thứ 3 và vì chúng "đáng tin cậy", có thể bị lạm dụng để tạo ra phần mềm độc hại.

Tất nhiên, sau đó, có các kịch bản phần mềm mà CA thậm chí không được gọi vào sử dụng - ví dụ: với các máy khách dày gọi Dịch vụ web, điều đó không làm phiền việc xác nhận chứng chỉ của máy chủ ....

Quan điểm của tôi là nếu bạn lo lắng về MITM qua SSL, thường xuyên hơn không, đó không phải là sự ép buộc của chính phủ sẽ làm bạn lo lắng. Thường có những cách dễ dàng và dễ tiếp cận hơn.
[.__.] Tôi thậm chí phản đối "Tin cậy đáng tin cậy" được gọi là "Đáng tin cậy" ... Chỉ vì tôi biết bạn là ai, không có nghĩa là tôi nên tin tưởng bạn ... và điều đó không có nghĩa là tôi nên tin rằng bạn biết ai đó khác là.

Chưa kể, nếu bạn loại bỏ các root root tiêu chuẩn khỏi cửa hàng đáng tin cậy, nhiều trang web trên internet sẽ không hoạt động như mong đợi.

Mặt khác, nếu bạn đang làm việc với một máy chủ/thiết bị không thì không cần các khả năng duyệt chung, nhưng đang liên lạc với một máy chủ cụ thể (hoặc bộ máy chủ), chắc chắn xóa [~ # ~] tất cả [~ # ~] certs gốc, ngoại trừ danh sách trắng những cái bạn cần.
[.__.] Và nếu bạn đi với CA nội bộ của chính mình, thậm chí còn tốt hơn ....

11
AviD

Mỗi CA xuất bản Tuyên bố thực hành chứng chỉ mô tả cách họ bảo vệ khóa riêng của họ và xác thực các yêu cầu cho chứng chỉ trước khi cấp chúng. Một URL đến vị trí cho tài liệu này thường được nhúng trong mỗi chứng chỉ do CA. Giả sử rằng CA trong câu hỏi thực sự tuân theo tài liệu chính sách này, nó sẽ cung cấp cho bạn một dấu hiệu về độ dài mà họ đi để xác định tính hợp lệ của thực thể yêu cầu chứng chỉ. Tìm kiếm các tuyên bố về tác động mà chúng bảo vệ các khóa ký CA của chúng bằng Mô-đun bảo mật phần cứng hoặc Mô-đun mật mã để bảo vệ các khóa ký, xác thực đa yếu tố và ủy quyền dựa trên đại biểu để ký chứng chỉ, v.v. Các phương pháp bảo vệ này làm cho nó khó hơn và tốn kém hơn cho một bên thứ ba lừa đảo để đánh cắp các khóa ký.

Danh sách khổng lồ các CA đáng tin cậy (Mac System Roots Keychain của tôi có 175) để thuận tiện cho bạn, để làm cho hệ thống HTTPS có thể sử dụng được cho bạn và mọi người trên hành tinh không hỏi những câu hỏi này. Tất nhiên, bạn có thể loại mọi CA ra khỏi danh sách này trừ khi bạn đã trực tiếp kiểm tra thực hành của họ. Đối với một hệ thống khép kín, nơi bạn kiểm soát tất cả các điểm cuối và bạn có số lượng bên đáng tin cậy hạn chế, điều này là có thể thực hiện được. Hệ thống kiểm soát phiên bản Subversion không bao gồm bất kỳ chứng chỉ Root đáng tin cậy nào, nhưng bạn có thể thêm chính bạn vào mọi máy khách. Đối với web nói chung, cách duy nhất chúng tôi tìm thấy để có thể sử dụng được là có một bên đáng tin cậy ngoài công ty (công ty cung cấp hệ điều hành hoặc trình duyệt của bạn, bất cứ điều gì bạn có thể nghĩ về họ) cung cấp danh sách đáng tin cậy chứng chỉ cho phép bạn kết nối với khá nhiều máy chủ hỗ trợ SSL trên thế giới.

Bạn có thực sự cần tất cả các chứng chỉ trong danh sách đáng tin cậy của bạn? Chắc là không. Nhưng nhà cung cấp hệ điều hành/trình duyệt của bạn không thể lường trước (và không nên kiểm soát) bạn muốn hợp tác với ai, vì vậy họ bao gồm tất cả họ. Vấn đề với danh sách lớn là bạn có CA của tất cả các bộ lông, với tất cả các loại phương pháp xác minh, từ tất cả các khu vực pháp lý, được đối xử giống hệt nhau. Không phải mọi CA đều hoạt động giống nhau: chúng tôi đã thấy các trường hợp thông tin đăng nhập của người bán lại bị xâm phạm và thậm chí các khóa CA bị xâm phạm. Một số CA yêu cầu chứng nhận hợp nhất và lời hứa của con đầu lòng của bạn, những người khác chỉ cần xác minh rằng bạn có thể nhận e-mail trên tên miền mà bạn đang yêu cầu chứng nhận. Tuy nhiên, mỗi CA được xử lý giống hệt nhau bởi trình duyệt của bạn.

Một dòng bảo vệ chống lại các chứng chỉ giả mạo cho cùng một Tên chung sẽ là lưu trữ chứng chỉ gốc trên máy khách: nếu một chứng chỉ khác từ một CA khác đột nhiên xuất hiện, điều này sẽ gây lo ngại. Tôi không biết các trình duyệt ngày nay xử lý trường hợp này như thế nào và tôi quá lười để tìm hiểu.

9
Sander Temme

Kiểu thảo luận này luôn khiến tôi nhớ đến lỗi Mozilla này yêu cầu đưa vào một CA mới. Khá vui nhộn, nhưng khá sâu sắc.

4
Steve Dispensa

Khi nghiên cứu loại chứng chỉ nào cần xóa trong PC Windows, trước tiên bạn nên đảm bảo rằng bạn không xóa chứng chỉ theo yêu cầu hệ thống. Nếu bạn cố gắng làm như vậy, bạn sẽ nhận được thông báo lỗi sau

error- you're deleting a system cert!!

Đây là URL với danh sách các certs không bao giờ bị xóa khỏi hệ thống windows http: //support.Microsoft.com/? Id = 293781

Tiếp theo, bạn nên xem xét loại bỏ (kiểm tra loại bỏ) chứng chỉ trung gian, vì chúng chỉ tồn tại " hoàn toàn vì lý do di sản ".

Khi đánh giá loại bỏ tất cả các chứng chỉ còn lại, hãy xem xét rằng Chương trình chứng chỉ gốc của Microsoft yêu cầu CA vượt qua một trong các tiêu chuẩn kiểm toán này:

  • ETSI 102 042
  • ETSI 101 456
  • WebTrust cho CA
  • WebTrust EV sẵn sàng kiểm toán
  • ISO 21188 (Lưu ý rằng họ không chấp nhận ISO 27001)

Nếu bạn đang xóa Certs khỏi trình duyệt không phải MSFT (IE) thì bạn có thể muốn xem lại các nguyên tắc chất lượng CA này .

Hạn chế

Chương trình cũng có các kiểm toán bổ sung áp dụng cho việc sử dụng khóa là gì. Việc sử dụng chính được giới hạn ở những điều sau đây:

  • Xác thực máy chủ (SSL) = 1.3.6.1.5.5.7.3.1

  • Xác thực ứng dụng khách (SSL) = 1.3.6.1.5.5.7.3.2

  • E-mail an toàn (SMIME) EKU = 1.3.6.1.5.5.7.3.4

  • Ký mã EKU = 1.3.6.1.5.5.7.3.3

  • Thời gian dập EKU = 1.3.6.1.5.5.7.3.8

  • EKU OCSP = 1.3.6.1.5.5.7.3.9

  • Hệ thống tệp mã hóa EKU = 1.3.6.1.4.1.311.10.3.4

  • IPSec (Đường hầm, Người dùng) EKU = 1.3.6.1.5.5.7.3.6, 1.3.6.1.5.5.7.3.7

Công dụng chính bị cấm

Các cách sử dụng chính sau đây bị chương trình cấm:

  • Đăng nhập thẻ thông minh Đây là một kịch bản chỉ dành cho doanh nghiệp, vì cần phải triển khai Active Directory và root phải được thêm vào cửa hàng NTAuth trong Active Directory. Xem bài viết KB sau để biết chi tiết. http: //support.Microsoft.com/default.aspx? scid = kb; en-us; Q281245

  • Quyền kỹ thuật số EKU này đã lỗi thời. Windows Media DRM sử dụng định dạng XML riêng cho giấy phép và không sử dụng X.509.

  • Cấp dưới đủ tiêu chuẩn EKU này đã lỗi thời và bị Windows bỏ qua.

  • Phục hồi chính kịch bản CA doanh nghiệp.

  • Phục hồi tệp EKU này đã lỗi thời và bị Hệ thống tệp mã hóa Windows (EFS) bỏ qua.

  • Tất cả các chính sách ứng dụng Chúng tôi không thể cấp cho tất cả các ứng dụng khác vì điều này nhất thiết phải chấp nhận các EKU chỉ dành cho doanh nghiệp và không được chấp nhận khác.

  • Thư mục dịch vụ sao chép email Kịch bản doanh nghiệp

  • Giấy chứng nhận đại lý

  • Kịch bản CA doanh nghiệp

  • Kịch bản phục hồi đại lý CA doanh nghiệp

  • Chứng chỉ mã hóa CA

  • Kịch bản CA doanh nghiệp

Tiêu chí chấp nhận

Ngoài ra, các tiêu chí sau phải được đáp ứng trước khi thêm mục đích chung hoặc CA chính phủ vào thư mục gốc:

  1. CA phải cung cấp thông tin được yêu cầu bên dưới (xem Bước 1. Liên hệ với Microsoft ) và nhận phê duyệt sơ bộ cho tư cách thành viên trong Chương trình.

  2. CA phải cung cấp chứng chỉ kiểm tra được cấp từ chứng chỉ gốc CA CA cho mục đích thử nghiệm. Tùy chọn, CA có thể cung cấp cho Microsoft URL của máy chủ có thể truy cập công khai nơi chứng chỉ được cấp từ chứng chỉ gốc có thể được xác minh. (Xem FAQ để biết chi tiết)

  3. CA phải hoàn thành Thỏa thuận CA của Microsoft. Thỏa thuận sẽ chỉ được cung cấp sau khi bạn hoàn thành Bước 1 của quy trình đăng ký và nhận được phê duyệt sơ bộ cho đơn đăng ký của bạn.

  4. Chứng chỉ gốc phải tuân thủ phần Yêu cầu kỹ thuật bên dưới. Cụ thể, chúng tôi yêu cầu kích thước khóa mật mã tối thiểu của mô đun RSA 2048 bit cho bất kỳ root và tất cả các CA phát hành. Microsoft sẽ không còn chấp nhận chứng chỉ gốc với mô đun RSA 1024 bit khi hết hạn. Chúng tôi muốn rằng các gốc mới có giá trị ít nhất 8 năm kể từ ngày nộp nhưng hết hạn trước năm 2030, đặc biệt nếu chúng có mô-đun RSA 2048 bit.

  5. Chứng chỉ được cấp từ chứng chỉ gốc phải hỗ trợ phần mở rộng điểm phân phối CRL. Điểm phân phối CRL phải trỏ đến một vị trí có thể truy cập công khai.

  6. CA phải có chính sách thu hồi tài liệu và CA sẽ có thể thu hồi bất kỳ chứng chỉ nào họ cấp.

  7. CA phải hoàn thành kiểm toán và gửi kết quả kiểm toán cho Microsoft cứ sau 12 (12) tháng. Kiểm toán phải bao gồm toàn bộ hệ thống phân cấp PKI sẽ được Microsoft kích hoạt thông qua việc gán Sử dụng khóa mở rộng (EKU). Tất cả các sử dụng chứng chỉ mà chúng tôi kích hoạt phải được kiểm toán định kỳ. Báo cáo kiểm toán phải ghi lại toàn bộ phạm vi của hệ thống phân cấp PKI bao gồm mọi CA phụ phát hành một loại chứng chỉ cụ thể được bao phủ bởi một cuộc kiểm toán. Kiểm toán đủ điều kiện bao gồm:

Đây là những kiểm toán được chấp nhận tại thời điểm này đối với các CA phi chính phủ. Chúng tôi có quyền thay đổi các cuộc kiểm toán được liệt kê ở trên và/hoặc chấp nhận các cuộc kiểm toán tương đương khác trong tương lai.

Yêu cầu kỹ thuật

Chứng chỉ gốc mới phải đáp ứng các yêu cầu kỹ thuật sau:

  • Chứng chỉ gốc phải là x.509 v3 chứng chỉ.

  • Tên chủ đề phải chứa một tên có ý nghĩa của CA (ví dụ: không thể là Root Root hay hoặc CA CA1)

  • Phần mở rộng ràng buộc cơ bản: cA = true

  • Sử dụng khóa (nếu có): keyCertSign và cRLSign chỉ

  • Yêu cầu Kích thước khóa gốc dựa trên NIST SP 800-57 :

         RSA greater or equal to 2048-bit modulus
    
         ECC greater or equal to P256 modulus
    
  • Thuật toán băm phải ít nhất là SHA1. Không có băm MD2, MD4 hoặc MD5 được chấp nhận.

  • Đối với kích thước khóa gốc lớn hơn hoặc bằng mô đun RSA 2048 bit, chứng chỉ gốc không được hết hạn cho đến ít nhất 8 năm sau khi gửi và không muộn hơn 2030. Có thể hết hạn sử dụng cho kích thước khóa gốc lớn hơn.

  • Chứng chỉ CA trung gian được loại trừ khỏi Chương trình CA gốc (Xem Câu hỏi thường gặp để biết thêm thông tin)

  • CA sẽ không cấp chứng chỉ cấp dưới hoặc thực thể cuối MD2, MD4 hoặc MD5 từ bất kỳ chứng chỉ gốc nào được phân phối bởi Chương trình, có hiệu lực từ ngày 15 tháng 1 năm 2009.

  • Các chứng chỉ gốc RSA 1024 bit hiện tại có thể vẫn được phân phối bởi Chương trình cho đến thời hạn NIST ngày 31 tháng 12 năm 2010, trừ khi được Microsoft cung cấp.

  • CA có thể cấp chứng chỉ RSA 1024 bit từ chứng chỉ gốc được Chương trình phân phối cho đến thời hạn NIST ngày 31 tháng 12 năm 2010.

3
goodguys_activate

Tôi tin rằng chính phủ Hoa Kỳ đã cố gắng thông qua luật một vài năm trước, cho họ quyền buộc CA tạo ra một chứng chỉ hợp lệ của bên thứ 3 để nghe lén và không. Tôi không thể tìm thấy bằng chứng về điều này, vì vậy tôi có thể đang nhớ một cái gì đó dọc theo các cuộc thảo luận về DefCon mà Rory đã đề cập.

3
Steve

Giả sử một số chính phủ xấu muốn xem lưu lượng SSL của máy. Làm thế nào khả thi để CA mặc định bị ép buộc cấp giấy chứng nhận mới?

Vị ngữ và câu hỏi không liên quan. Việc CA có thể bị ép buộc cấp chứng chỉ mới dễ dàng hay thường xuyên như thế nào - kẻ nghe trộm sẽ không thể nhìn thấy dữ liệu của bạn trừ khi họ có khóa riêng từ chứng chỉ bạn đã cài đặt. IIRC (nhưng tôi khuyên bạn nên kiểm tra điều này) CSR không bao gồm khóa riêng - vì vậy CA không thể hiểu theo cách đó. Họ không thể thay đổi những phím nào mà máy của bạn đang sử dụng.

Tuy nhiên, có thể một CA lừa đảo có thể cấp chứng chỉ giả mạo - và tiềm năng sau đó tồn tại cho một cuộc tấn công MITM trên trang web của bạn. Các vấn đề gần đây với định dạng MD5 và Etaluat cho thấy rằng điều đó không phải là không thể.

3
symcbean

Cố gắng tập trung vào câu hỏi thứ hai.

Vấn đề "Tôi nên xóa chứng chỉ gốc đáng tin cậy mặc định nào?" về cơ bản phụ thuộc vào người mà bạn đối phó.

Bạn sẽ "chỉ" cần tin tưởng tất cả các CA ký bất kỳ trang web nào bạn kết nối.

Đối với người dùng loại bà luôn truy cập vào cùng một vài trang web, có thể một số ít CA sẽ là đủ, trong khi danh sách sẽ không tăng nhanh * cho người dùng internet nặng.

Tại sao không nhanh chóng ? Ngược lại, một số CA được sử dụng rất nhiều (bao gồm cả những cái quá lớn để thất bại) trong khi những cái khác chỉ được sử dụng hiếm khi trên internet, như một số gần như theo địa lý.

Công cụ SSLCop từ securitybydefault có thể giúp chặn các quốc gia bạn không tin tưởng/không có khả năng cần đến (ví dụ: bạn không mong muốn truy cập vào trang web từ chính phủ Brobdingnag, tình cờ là người dùng chính của CA đó): http://www.security-projects.com/?SSLCop

Tuy nhiên, nếu bạn không tin tưởng quá nhiều CA, cuối cùng bạn sẽ không thể có được một mỏ neo tin cậy cho các trang web mà người dùng của bạn cần (và họ sẽ truy cập chúng dù sao, bất chấp cảnh báo an ninh), đó là xấu không kém.

1
Ángel

Trình diễn việc tạo một CA lừa đảo bằng các điểm yếu MD5:

1
Bradley Kreider

Kể từ ngày 12 tháng 6 năm 2012, Microsoft đã phát hành một trình cập nhật mới sẽ vô hiệu hóa các chứng chỉ gốc không đáng tin cậy và bất kỳ chứng chỉ nào khác được báo cáo cho Microsoft là không đáng tin cậy.

Bản cập nhật có sẵn ở đây và tôi không rõ liệu bản cập nhật này đã được phân phối thông qua Cập nhật Windows hay chưa, nếu đó là bản cập nhật ngoài băng.

http://support.Microsoft.com/kb/267707

0
goodguys_activate