Lỗi SSL và chứng chỉ hết hạn

Question

Câu hỏi này liên quan đến việc sử dụng SSL Pinning trong ứng dụng khách đối với api web và chứng chỉ hết hạn.

Kịch bản:

tôi sở hữu example.com và có một tên miền phụ, nơi một api được lưu trữ, như vậy: api.example.com

Tôi muốn sử dụng api trên SSL, do đó, Chứng chỉ SSL được tạo cho tên miền phụ.

Sau khi giấy chứng nhận đã được mua lại, tôi có:

• Một Giấy chứng nhận Giấy chứng nhận Công
• Một Intermediate
• Một Private Key

Đó là sự hiểu biết của tôi mà tôi cài đặt các chứng chỉ trên máy chủ web của tôi.

Sau đó tôi muốn ứng dụng khách của tôi kết nối với api. Để giảm thiểu các cuộc tấn công của người đàn ông trung gian , tôi muốn sử dụng SSL Pinning, để khách hàng sẽ chỉ liên lạc với api của tôi, chứ không phải ai đó đang giả mạo nó.

Để ghim trong ứng dụng khách, tôi có hai lựa chọn, hoặc là chống lại chứng chỉ công khai hoặc trung gian .

Giả sử tôi triển khai điều này.

Điều gì xảy ra khi chứng chỉ trên api.example.com hết hạn?

Tôi hiểu rằng ứng dụng khách sẽ không hoạt động nữa.

Tôi có cần phải tạo lại toàn bộ các mục công khai/trung gian/riêng tư không? và sau đó đặt chứng chỉ công khai hoặc trung gian mới trong ứng dụng?

Câu hỏi:

tôi sẽ vẫn giống như các ứng dụng client để làm việc cho đến khi chứng chỉ trên api.example.com đã được cập nhật. Tất nhiên, một chứng chỉ mới có thể được đưa vào ứng dụng của khách hàng, nhưng những thứ như thời gian đưa ra sẽ mất thời gian.

Tôi làm cách nào để xử lý việc này?

Tôi đã đọc rằng Google cập nhật giấy chứng nhận của họ mỗi tháng, nhưng bằng cách nào đó quản lý để giữ cho các khóa công khai như nhau: How to pin the Public key of a certificate on iOS

Nếu đó là có thể, sau đó giải pháp là chỉ cần trích xuất khóa công khai từ máy chủ và kiểm tra nó với khóa công cộng được lưu trữ cục bộ ... nhưng Google làm như thế nào?

Cảm ơn

Chris

Answer 1

Lưu ý: Tôi quen thuộc hơn với trình duyệt đến máy chủ ghim (HTTP Public Key Ghim cho - HPKP) chứ không phải là ứng dụng máy chủ ghim, nhưng tôi đoán hiệu trưởng là như nhau. Trong HPKP, chính sách ghim được máy chủ cung cấp dưới dạng tiêu đề HTTP nhưng hiểu điều này thường được tích hợp vào ứng dụng thay vì đọc từ phản hồi HTTP. Vì vậy, hãy đọc câu trả lời dưới đây với tất cả ý nghĩ đó:

Ghim thường chống lại khóa không phải là chứng chỉ và có thể là nhiều cấp độ. Vì vậy, bạn có một số lựa chọn:

1. Sử dụng lại cùng một khóa/crt để tạo chứng chỉ mới. Một số (đúng theo ý kiến ​​của tôi!) Khuyên bạn nên tạo ra một khóa mới mỗi khi bạn gia hạn cert của bạn nhưng điều này là phức tạp khi bạn sử dụng ghim. Vì vậy, không ghim khuyến khích thói quen an ninh kém như tái sử dụng chính?

2. Có một vài phím sao lưu trong chính sách ghim của bạn và xoay vòng chúng xung quanh việc gia hạn cert hủy cũ nhất của bạn và thêm mới với nhiều thời gian và cập nhật để không bao giờ bị phát hiện. Cá nhân tôi muốn tạo ra chìa khóa tại thời gian gia hạn cert thay vì có một số bản sao lưu xung quanh mà có thể hoặc có thể đã bị xâm nhập vì vậy tôi không phải là một fan hâm mộ cụ thể này. Và bạn nên có bao nhiêu bản sao lưu? Ví dụ. Nếu bạn cần phát hành lại một chứng nhận vì sự thỏa hiệp xung quanh việc gia hạn và cũng làm hỏng nó? Vì vậy, 2? 3? 100?

3. Ghim thêm. Nói đầu tiên trung gian hoặc gốc CA cert. Vì vậy, bất kỳ cert mới được phát hành vẫn còn đáng tin cậy (cung cấp nó được phát hành bởi cùng một đường dẫn cert) Nhược điểm của điều này là bốn lần: i) Bạn vẫn để lại cho mình mở để lỡ phát hành certs do certned pinned (không phải là một thỏa thuận lớn IMHO như bạn vẫn giảm ồ ạt bề mặt tấn công của bạn nhưng vẫn là một mối quan tâm với một số người), ii) bạn không thể đảm bảo rằng khách hàng sẽ sử dụng chứng chỉ trung gian đó vì đôi khi có nhiều đường dẫn hợp lệ. Điều thứ hai này là một thỏa thuận lớn hơn nhiều. Bạn nghĩ rằng việc cung cấp cert trung gian sẽ đảm bảo điều này sẽ được sử dụng nhưng đó không phải là trường hợp (nhiều ví dụ sha-1 về điều này). iii) Không có đảm bảo rằng chứng chỉ mới sẽ được phát hành bởi cùng một trung gian hoặc gốc (đặc biệt là khi các công nghệ thay đổi như giới thiệu của sha2), vì vậy với tôi toàn bộ tùy chọn này là không bắt đầu iv) không phải là một vấn đề lớn nhưng tôi thích tự do di chuyển). Bạn không chắc chắn liệu các ứng dụng có hỗ trợ tính năng này nguyên bản hay không nhưng trình duyệt chắc chắn sẽ làm.

4. Gia hạn trước và không sử dụng khóa mới cho đến khi bộ nhớ cache chính sách hết hạn. Ví dụ: nếu bạn có chứng chỉ một năm và chính sách ghim trong 30 ngày thì bạn có thể gia hạn sau 11 tháng, thêm khóa mới vào chính sách, sau đó chờ 30 ngày để bạn có thể chắc chắn mọi người sẽ nhận chính sách mới hoặc ít nhất chính sách cũ sẽ hết hạn, sau đó chuyển khóa và chứng chỉ. Tùy thuộc vào chính sách ngắn và có khả năng lãng phí một phần của chính sách đó (ít nhất 30 ngày trong ví dụ này), trừ khi nhà cung cấp cert cung cấp cert trước bắt đầu vào ngày sau khi chính sách cũ hết hạn. Đối với một ứng dụng, nếu chính sách ghim được mã hóa cứng vào nó, thì điều này có thể kéo dài khoảng thời gian cần thiết để đẩy ra bản cập nhật.

Cuối cùng, vì các chứng chỉ yêu cầu làm mới, tôi không phải là người hâm mộ lớn ghim. Tôi không nghĩ rằng làm một cái gì đó mà là tùy thuộc vào việc gia hạn định kỳ, bán vĩnh viễn là câu trả lời đúng. Và thậm chí còn có một số cuộc trò chuyện về các chính sách ghim trước khi tải trong các trình duyệt khiến tôi rùng mình.

Ghim cung cấp đảm bảo rằng một CA giả mạo không phát hành chứng chỉ cho miền của bạn nhưng khả năng đó thực sự so với mức độ khó ghim như thế nào?Một cái gì đó giống như minh bạch chứng chỉ - hoặc thậm chí báo cáo chỉ ghim có thể là một câu trả lời tốt hơn cho vấn đề đó ngay cả khi họ không thực sự dừng cuộc tấn công đó.

Cuối cùng là các gốc được cài đặt cục bộ (ví dụ: cho máy quét chống vi-rút hoặc proxy của công ty), bỏ qua kiểm tra ghim (trên trình duyệt ít nhất), điều này lại làm giảm hiệu quả của nó trong mắt tôi.

Vì vậy hãy suy nghĩ cẩn thận trước khi sử dụng ghim và đảm bảo bạn hiểu tất cả các hậu quả.

Answer 2

mozilla developer site khuyên bạn nên ghim chứng chỉ của CA trung gian đã ký chứng chỉ máy chủ.

"bạn nên đặt ghim trên chứng chỉ trung gian của CA đã cấp chứng chỉ máy chủ, để giảm bớt gia hạn chứng chỉ và xoay vòng".

Để biết thêm thông tin về cách triển khai và thử nghiệm khóa khóa công khai, bạn có thể tham khảo Implementing and Testing HTTP Public Key Pinning (HPKP)