Hàng loạt các chứng chỉ SSL của Google, Apple, Godaddy bị thu hồi vì sai phạm

Hàng triệu chứng chỉ SSL / TLS – trong số các chứng chỉ kỹ thuật số khác – hiện đang bị thu hồi do lỗi vận hành gây ra việc tạo ra các số sê-ri không tuân thủ.

 

Làm thế nào để bạn cấp sai hàng triệu chứng chỉ?

Hãy bắt đầu với khía cạnh kỹ thuật của những gì đã xảy ra. Nếu bạn không thực sự muốn nghe về số sê-ri và entropy, hãy tiếp tục và bỏ qua phần tiếp theo. 

Hãy bắt đầu với EJBCA, đây là gói phần mềm ủy quyền chứng chỉ nguồn mở. Nó có thể được sử dụng riêng để xây dựng cơ sở hạ tầng PKI hoàn chỉnh, nhưng nhiều CA đáng tin cậy công khai sử dụng nó làm Trình tạo số giả mã hóa bảo mật (CSPRNG) để tạo số sê-ri.

Số sê-ri được đề cập trong Yêu cầu cơ bản của Diễn đàn CA / B , phần 7.1:

CA SHALL tạo số sê-ri Chứng chỉ không tuần tự lớn hơn 0 (0) chứa ít nhất 64 bit đầu ra từ CSPRNG

Đây là nơi mọi thứ trở nên tồi tệ một chút, các số sê-ri này phải là số nguyên duy nhất, dương với 64 bit entropy. Điều đó đòi hỏi một trong 64 bit phải là một giá trị cố định để đảm bảo rằng số sê-ri là dương. Thật không may, các cài đặt mặc định cho EJBCA đã không tính đến chi tiết đó và thay vào đó đã tạo ra các số sê-ri 63 bit.

Tại sao đó là một vấn đề lớn? Adam Caudill đã giải thích nó trên blog của mình :

Khi chúng ta đang nói về những con số lớn như vậy, thật dễ dàng để nghĩ rằng 1 bit sẽ không tạo ra nhiều khác biệt, nhưng sự khác biệt giữa 2^64và 2^63là đáng kể – cụ thể, đã 2^63giảm hơn 9 triệu hoặc cụ thể hơn là 9.223.372.036.854.775.808.

Điều đó thể hiện một rủi ro không thể chấp nhận được đối với một hệ sinh thái. Do đó, mọi chứng chỉ có số sê-ri 63 bit được tạo bằng mặc định EJBCA phải được thu hồi và thay thế bằng chứng chỉ tuân thủ.

Điều đó, tự nó, là một vấn đề lớn. Đó là một sự gián đoạn kinh doanh lớn. Nhưng đó không thực sự là toàn bộ câu chuyện, bởi vì làm thế nào chúng ta đạt đến điểm này là như nhau, nếu không quan trọng hơn.

 

Cho đến nay Apple, Google và GoDaddy đã thừa nhận cấp giấy chứng nhận sai. GoDaddy ban đầu cho biết đó là 1,8 triệu chứng chỉ, mặc dù họ đã sửa số đó xuống. Apple đã lấy tín dụng cho 878.000, mặc dù khoảng 300.000 trong số đó đã hết hạn hoặc bị thu hồi vào tuần trước. Google, trong khi đó, ước tính rằng họ đã phát hành hơn 100.000, mặc dù chỉ có khoảng 7.100 trong số đó vẫn còn hiệu lực.

Cũng có khả năng điều này cũng có thể ảnh hưởng đến các CA khác. Mặc dù cho đến thời điểm hiện tại, không ai tiết lộ bất kỳ hoạt động phát hành sai nào xuất phát từ việc cấu hình sai EJBCA.

Chúng tôi có thể, ít nhất là một phần, cảm ơn DarkMatter đã chỉ ra điều này. Những gì chúng ta có lẽ không nên làm – như chúng ta đã thảo luận trong bài viết tuần trước về chủ đề này – giữ nguyên lý do này để từ chối ứng dụng gốc của nó.

Không phải nói rằng bài viết của chúng tôi là đặc biệt trước, nhưng:

Và điều gì xảy ra nếu, bằng cách áp dụng tiêu chuẩn đó cho các CA được thành lập khác, nó cũng buộc chúng ta phải đánh giá lại sự tham gia của họ? Hay chúng ta chỉ đơn giản là bỏ qua việc áp dụng các tiêu chuẩn khác nhau cho các tổ chức khác nhau dựa trên vị trí của họ và các mối quan hệ đối tác khác?

Rủi ro nào đặt ra điều này?

Một rủi ro kinh doanh, chắc chắn. Một rủi ro bảo mật? Không. 64 bit entropy cần thiết cho các số sê-ri tuân thủ BR là yêu cầu được thêm vào năm 2016 để đáp ứng với khái niệm bằng chứng giả mạo SSL có thể tạo ra xung đột (hai số sê-ri phù hợp) bằng thuật toán băm MD5 tại thời điểm đó, tạo ra chứng chỉ. Ngày nay các chứng chỉ được tạo bằng SHA-2 ( SHA256 trở lên ), vì vậy các lỗ hổng của MD5 không còn là vấn đề nữa.

Vì vậy, nhu cầu về 64 bit của entropy thực sự là một biện pháp bảo vệ chống lại các cuộc tấn công có thể được giả định trong tương lai.

Đây là một vấn đề lớn đối với các CA và khách hàng của họ, chanh Caudill nói với Ars Technica . Các tác động của việc thay thế số lượng lớn các chứng chỉ là đáng kể. Từ quan điểm đe dọa, điều này không thể khai thác. Nó sẽ đòi hỏi một bước đột phá lớn về mật mã, và thậm chí sau đó, 63 bit entropy cung cấp một biên độ an toàn rất lớn. Đây là một vấn đề vì tác động đến mọi người và các công ty; tin tặc sẽ không bắt đầu giả mạo chứng chỉ vì điều này.

Như Caudill đã ám chỉ, vấn đề lớn hơn là sự gián đoạn kinh doanh.

Đây sẽ là sự gián đoạn lớn thứ hai mà ngành công nghiệp chứng chỉ số đã phải đối mặt trong năm rưỡi qua – lần đầu tiên là sự mất lòng tin của Symantec .

Đó là một con mắt đen cho toàn bộ ngành công nghiệp. Hầu hết các doanh nghiệp và người tiêu dùng không suy nghĩ nhiều về các chứng chỉ kỹ thuật số cho đến khi chúng hết hạn hoặc bị hỏng. Và như chúng ta đã thảo luận gần đây, đối với nhiều doanh nghiệp chứng chỉ và quản lý chứng chỉ là vấn đề tuân thủ hơn là bảo mật . Và các doanh nghiệp không thích rủi ro không tuân thủ.

Chỉ cần nói rằng sẽ có rất nhiều tổ chức rất tức giận khi họ phát hiện ra các chứng chỉ mà họ sử dụng để giúp đảm bảo tuân thủ đang bị thu hồi vì không tuân thủ.

Nghe có vẻ như một cuộc trò chuyện thực sự thú vị.

Google không tin tưởng?

 

Tiêu đề này là lịch sự. Nhưng, một trong những nhánh khác của toàn bộ tình huống này là một số điểm tương đồng với sự không tin tưởng của Symantec đã nói ở trên . Chỉ lần này, Google đã cấp sai một loạt các chứng chỉ không gây ra mối đe dọa trong thế giới thực. Nếu bạn nhớ lại, Google thực tế đã buộc Symantec rời khỏi ngành sau khi phát hiện ra nó đã cấp sai 33 chứng chỉ kiểm tra vào năm 2016. Symantec tuyên bố rằng đó không phải là vấn đề vì chúng không có mối đe dọa thực sự. Google tuyên bố nó đại diện cho một sự vi phạm lòng tin không thể chấp nhận.

Rõ ràng có một số khác biệt, nhưng ở một mức độ nào đó, phát hành sai là phát hành sai. Và thực tế là Google đã không tự mình khám phá ra điều này.

Rõ ràng, vấn đề không phải là làm phật lòng Google – chỉ một lần nữa, chỉ ra tính chủ quan của rất nhiều những quyết định này. CA sẽ phát hành sai, nó xảy ra theo đúng nghĩa đen. Độc thân. Một. Phần quan trọng hơn là phản ứng.

GoDaddy đang dành 30 ngày để hoàn thành công việc của mình trong khi Apple và Google đang hoạt động theo các mốc thời gian ngắn hơn nhiều.

Điều đó có ý nghĩa. Apple và Google cấp chứng chỉ nội bộ, trong các tổ chức của chính họ. Họ không lo lắng về một loạt các khách hàng tức giận. GoDaddy cũng vậy, nhưng, cho bản thân 30 ngày cũng có thể khiến GoDaddy gặp nhiều rắc rối hơn từ quan điểm tuân thủ. Yêu cầu cơ bản bắt buộc phải thu hồi kịp thời tất cả các chứng chỉ không tuân thủ, theo mục 4.9.1.1:

CA NÊN thu hồi chứng chỉ trong vòng 24 giờ và PHẢI thu hồi Chứng chỉ trong vòng 5 ngày nếu xảy ra một hoặc nhiều trường hợp sau:

7. CA được biết rằng Chứng chỉ không được cấp theo các Yêu cầu này hoặc Chính sách chứng nhận hoặc Tuyên bố thực hành chứng nhận của CA; Giáo dục

Tôi đã nói rằng rõ ràng các chương trình gốc sẽ không tin tưởng GoDaddy, nhưng ba năm trước tôi có thể đã nói điều tương tự về Symantec vì vậy tôi sẽ để nó ở đó.

Trong khi đó, nhiều trang web và tổ chức sẽ tranh giành để thay thế chứng chỉ SSL / TLS của họ – bên cạnh nhiều chứng chỉ ký mã & email – bằng các chứng chỉ tuân thủ.

bình luận

Leave a Comment