Kiểm thử thu hồi chứng thư TLS: OCSP stapling, CRL và responder outage

Bài kiểm thử phải trả lời: client lấy trạng thái thu hồi ở đâu; server có staple OCSP response đúng chain và còn hiệu lực không; client làm gì khi không thể kiểm tra; revocation được phản ánh sau bao lâu; và failover responder có tạo latency hoặc outage diện rộng không. Đây là kiểm thử policy lẫn interoperability, không chỉ kiểm tra một extension trong certificate.

Chỉ dùng CA/private PKI hoặc môi trường staging do nhóm kiểm thử kiểm soát. Không thu hồi certificate production để “thử nhanh”, không giả mạo responder ngoài lab và không gửi private key vào công cụ không được phê duyệt. Certificate, CRL và OCSP response phải có serial, thời gian và chain được ghi lại.

Topology gồm root/intermediate CA lab, TLS server, OCSP responder chính/phụ, HTTP endpoint phân phối CRL, DNS có thể inject lỗi, network emulator và tập client đại diện: trình duyệt, Java/.NET runtime, reverse proxy, API client, thiết bị nhúng hoặc appliance. Đặt capture tại client–server và responder; thu log từ CA/responder.

Chuẩn bị certificate cho các trạng thái good, revoked và serial unknown; certificate có và không có TLS Feature/Must-Staple; CRL base và bản cập nhật nếu hạ tầng hỗ trợ; stapled response fresh, stale, sai serial, sai issuer hoặc chữ ký không hợp lệ. Mỗi artifact gắn ID để truy ngược kết quả.

Khóa chain, signature algorithm, key size, AIA/CDP URL, thisUpdate, nextUpdate, clock source, DNS, proxy, cache và network path. Ghi rõ client/runtime/version và cờ revocation checking vì nhiều nền tảng có hành vi mặc định khác nhau; không suy từ browser A sang agent B.

Phân biệt server-side stapling cache với client-side status cache. Sau mỗi thay đổi trạng thái, hoặc làm sạch cache theo quy trình được hỗ trợ, hoặc coi cache là biến số cần đo. Thay clock chỉ trong VM/container lab và ghi độ lệch; tránh làm lệch NTP trên hệ thống dùng chung.

Không giả định container có clock wall-time độc lập với host. Nếu cần thay CLOCK_REALTIME, dùng VM hoặc cơ chế clock injection được ứng dụng hỗ trợ, tránh cấp quyền thay giờ cho container trên máy dùng chung. OCSP good cũng không tự chứng minh certificate đã được cấp hợp lệ: vẫn cần kiểm chain, tên, thời hạn và chữ ký.

• Biến số: Client/runtime · Giá trị cần ghi: tên, build, revocation policy · Tác động: Quyết định soft-fail/hard-fail
• Biến số: Certificate chain · Giá trị cần ghi: issuer, serial, AIA/CDP · Tác động: Xác định nguồn trạng thái
• Biến số: OCSP timing · Giá trị cần ghi: producedAt/thisUpdate/nextUpdate · Tác động: Quyết định response fresh/stale
• Biến số: Stapling · Giá trị cần ghi: bật/tắt, refresh interval · Tác động: Ảnh hưởng handshake và tải responder
• Biến số: CRL · Giá trị cần ghi: số, thời hạn, kích thước · Tác động: Ảnh hưởng download/cache
• Biến số: Network fault · Giá trị cần ghi: timeout, reset, DNS, 5xx · Tác động: Các lỗi có thể được xử lý khác nhau

KPI gồm tỷ lệ handshake thành công/thất bại theo trạng thái, TLS handshake latency p50/p95/p99, request rate tới OCSP/CRL, cache hit, thời gian từ publish revocation đến client chặn, và thời gian phục hồi sau responder outage. Với hệ thống fail-closed, theo dõi availability; với fail-open, theo dõi security exposure window.

Bằng chứng tối thiểu: certificate chain và serial; OCSP request/response hoặc stapled response; CRL number và entry; PCAP; log server/client/responder; cấu hình policy; timestamp đồng bộ; exit code hoặc lỗi xác minh của client. Không coi một ảnh màn hình “certificate revoked” là đủ để tái lập.

Pass/fail phải theo từng client. Ví dụ “ứng dụng Java production phải fail-closed khi certificate revoked” là tiêu chí kiểm thử; “mọi trình duyệt đều hard-fail” là giả định không an toàn nếu chưa xác minh phiên bản và cơ chế riêng.

• Ca: REV-01 · Artifact/sự kiện: Cert good, OCSP fresh · Kỳ vọng phải xác định trước: Handshake theo policy · Bằng chứng: Staple/OCSP, client log
• Ca: REV-02 · Artifact/sự kiện: Cert revoked · Kỳ vọng phải xác định trước: Bị chặn nếu revocation enforce · Bằng chứng: Serial, revocation time, error
• Ca: REV-03 · Artifact/sự kiện: OCSP unknown · Kỳ vọng phải xác định trước: Hành vi theo client policy · Bằng chứng: OCSP status, handshake result
• Ca: REV-04 · Artifact/sự kiện: Staple stale · Kỳ vọng phải xác định trước: Refresh hoặc fail theo policy · Bằng chứng: thisUpdate/nextUpdate, server log
• Ca: REV-05 · Artifact/sự kiện: Must-Staple nhưng thiếu staple · Kỳ vọng phải xác định trước: Client hỗ trợ phải xử lý đúng · Bằng chứng: Certificate extension, client result
• Ca: REV-06 · Artifact/sự kiện: Responder timeout/DNS fail · Kỳ vọng phải xác định trước: Fail-open/closed đã duyệt · Bằng chứng: Fault timeline, latency/error
• Ca: REV-07 · Artifact/sự kiện: CRL chứa serial revoked · Kỳ vọng phải xác định trước: Client dùng CRL phải chặn · Bằng chứng: CRL dump, cache, client log
• Ca: REV-08 · Artifact/sự kiện: Clock ± lệch lab · Kỳ vọng phải xác định trước: Không chấp nhận response ngoài validity · Bằng chứng: Clock, response timing, error

Trước tiên, kết nối với stapling tắt và quan sát client có truy vấn responder hay không. Sau đó bật stapling, kiểm CertificateStatus/extension phù hợp trong handshake, đối chiếu serial, issuer, signature và thời hạn. Lặp khi OCSP response sắp hết hạn để đo refresh behavior và nguy cơ server tiếp tục phát staple stale.

Với revoked và unknown, tạo trạng thái ở CA lab, publish response mới rồi đo propagation. Với certificate có TLS Feature status_request (thường gọi Must-Staple), thử staple thiếu, stale và sai. RFC 7633 định nghĩa extension, nhưng mức hỗ trợ client phải được kiểm tra thực tế; không dùng một client hỗ trợ để suy ra toàn bộ fleet.

Phát CRL không chứa serial, rồi CRL mới chứa serial revoked. Đo download, cache và thời gian client chuyển sang chặn. Thử CRL lớn ở mức an toàn để quan sát latency và memory; nếu dùng delta CRL, kiểm base/delta sequencing. Inject 404, timeout, DNS failure và content lỗi tại CRL Distribution Point.

Với outage OCSP, thử TCP reset, TLS lỗi nếu responder dùng HTTPS, HTTP 5xx, response chậm và responder phụ. Đo cả cold cache lẫn warm cache. Sau đó lệch clock client/server trong lab quanh thisUpdate/nextUpdate để xác minh cửa sổ chấp nhận. Khôi phục NTP và kiểm hệ thống quay về baseline, không giữ trạng thái lỗi vô thời hạn.

Trong báo cáo, tách “client không kiểm revocation”, “client kiểm nhưng soft-fail” và “client hard-fail”. Ba trường hợp có rủi ro khác nhau và cần action owner khác nhau: cấu hình ứng dụng, thiết kế responder/cache, hoặc thay đổi certificate policy.

• Chụp cấu hình CA, responder, server, client, clock và network path.
• Xác minh baseline chain/trust với certificate good.
• Lưu OCSP/CRL artifact và hash trước từng ca.
• Làm sạch cache theo phương pháp được hỗ trợ hoặc ghi rõ warm-cache.
• Chạy từng trạng thái; thu handshake, log và responder counter.
• Inject một lỗi mạng mỗi lần; đo latency, outcome và recovery.
• Lặp trên từng client/runtime/version production.
• Khôi phục clock, DNS, responder và certificate; chạy smoke test cuối.

Hành vi revocation có thể thay đổi theo OS trust store, browser service, enterprise policy, library build và network environment. Lab private PKI không mô phỏng đầy đủ cơ chế phân phối riêng của browser hoặc CA công cộng. Kết luận chỉ áp dụng cho client, chain, policy và lỗi đã đo.

OCSP/CRL cũng không thay thế vòng đời key và incident response. Nếu private key bị lộ, cần thu hồi, xoay key/certificate, điều tra lạm dụng, cập nhật trust/pinning và xác minh propagation. Một handshake bị chặn không chứng minh toàn bộ phiên hoặc token đã bị vô hiệu hóa.

• OCSP: Giao thức hỏi trạng thái của một certificate cụ thể.
• OCSP stapling: Server gửi kèm OCSP response trong TLS handshake.
• CRL: Danh sách certificate bị thu hồi do CA ký.
• Must-Staple: TLS Feature yêu cầu client hỗ trợ xử lý sự hiện diện của status response.
• Soft-fail: Cho phép kết nối khi không kiểm được trạng thái.
• Hard-fail: Chặn kết nối khi trạng thái không đáp ứng policy.
• AIA/CDP: Extension chỉ tới dịch vụ issuer/OCSP hoặc điểm phân phối CRL.