CERTIFICATE VALIDATION with CRL, OCSP and OCSP tapling

Certificate Revocation

Mỗi một certificate được tạo ra đều có một khoảng thời gian hiệu lực (validity period ) nhất định và thường từ 1 hoặc 2 năm. Khi vượt ra khỏi khoảng thời gian này thì nó bị hết hạn và không còn giá trị nữa. Thông tin này được chứa trong bản thân certificate (giá trị valid from và valid to ) và cần được kiểm tra trước khi quyết định có nên tin dùng nó hay không.

Tuy nhiên, có những trường hợp mà một certificate cũng cần bị thu hồi (revoke) dù rằng thời gian hiệu lực vẫn còn như:

• Người sở hữu certificate không còn làm trong tổ chức nữa.
• CA phát hiện ra là đã cấp phát sai certificate. Sự cố liên quan tới các CA Comodo,DigiNotar xảy ra gần đây là một ví dụ.
• Private key bị lộ hoặc thiết bị chứa private key bị mất hoặc bị đánh cắp.

Công việc thu hồi certificate này được gọi là certificate revocation và do CA thực hiện.

Có 2 trạng thái revocation được quy định trong RFC 3280 là:

• Revoked: một khi certificate đã bị thu hồi thì không thể khôi phục lại và sử dụng tiếp được nữa.
• Hold: certificate chỉ tạm thời bị mất hiệu lực. Ví dụ, nếu người dùng không chắc là private key đã bị mất hay chưa thì CA có thể đưa certificate vào trạng thái hold. Nếu sau đó tìm thấy private key và chắc rằng không ai đã đọc được nó thì trạng thái hold được gỡ bỏ và certificate có hiệu lực trở lại.

Theo RFC 5280 thì khi thu hồi một certificate phải chỉ định một trong 11 lý do sau:

• unspecified (0)
• keyCompromise (1)
• cACompromise (2)
• affiliationChanged (3)
• superseded (4)
• cessationOfOperation (5)
• certificateHold (6)
• (value 7 is not used)
• removeFromCRL (8)
• privilegeWithdrawn (9)
• aACompromise (10)

CRL (Certificate Revocation List)

Là danh sách các certificate bị thu hồi và không còn được tin dùng nữa. Mỗi một mục (entry) trong CRL tương ứng với một certificate và thường gồm 3 thông tin sau:

• Serial number của certificate
• Thời điểm bị thu hồi
• Lý do thu hồi (là 1 trong 11 lý do kể trên)

Một CRL được tạo và phát hành (publish) định kỳ sau 1 khoảng thời gian nào đó do người quản trị CA chỉ định, ví dụ: 1 giờ, 1 ngày, 1 tuần, v.v. Một CRL cũng có thể được cập nhật và phát hành ngay sau khi một certificate nào đó bị thu hồi. Các CA sẽ đẩy CRL chứa các certificate do nó cấp phát và quản lý tới kho chứa là LDAP server hoặc Web server.

Để ngăn chặn nguy cơ CRL có thể bị làm giả dẫn đến certificate nào đó bị cố ý đưa vào hoặc bị loại bỏ khỏi CRL, các CRL đều có một chữ ký số được ký bởi CA đã phát hành nó. Và để xác thực chữ ký này trước khi có thể tin dùng CRL thì cần đến certificate của CA đã thực hiện việc ký trên. Thông thường certificate của các CA phổ biến đều được nạp sẵn bên trong các ứng dụng có hỗ trợ PKI như các trình duyệt web, đọc email hay hệ điều hành.

Khi ứng dụng PKI (Web Browser) nhận được một certificate, thì bản thân certificate không chứa nội dung của CRL mà nó có một extension là CRL Distribution Points (CDP), cho biết địa chỉ URL của CRL (là file có đuôi .crl) mà nó cần tải về. Sau đó ứng dụng PKI phải phân tích (parse) file .crl này để xác định xem certificate đã bị thu hồi hay chưa, nói cách khác nếu serial number không có trong CRL thì certificate đó có thể được tin dùng.

Có thể thấy, CRL mắc phải một số hạn chế sau:

• Nếu nhiều client cùng để tải về CRL từ kho chứa thì có nguy cơ làm tắc nghẽn, giảm hiệu suất mạng. Và nếu không thể kết nối tới kho chứa CRL do thì client không thể kiểm tra tính hiệu lực của certificate, dẫn đến certificate không được tin dùng.
• Qua thời gian, khi số lượng các certificate được cấp phát cũng như thu hồi ngày một tăng dần, thì kích thước của file .crl cũng tăng theo (thường từ 200KB đến 20MB). Ứng dụng PKI phải tốn thời gian tải về và phân tích file .crl thường chứa một lượng rất lớn các certificate bị thu hồi, trong khi nó chỉ cần xác định trạng thái revocation của một (vài) certificate mà thôi.
• Nếu certificate mà client cần kiểm tra đã bị thu hồi nhưng chưa được cập nhật vào CRL thì khi phân tích file .crl xong client vẫn chấp nhận certificate không còn hiệu lực đó!
• Mặc định, các máy Windows có timeout là 15 giây khi cố gắng tải về CRL.

Ngoài ra, còn có các delta CRL chứa thông tin revocation cho các certificate bị thu hồi kể từ khi base CRL mới nhất được phát hành. Nhưng để kiểm tra trạng thái revocation, ứng dụng PKI vẫn cần phải có đủ cả base CRL và các delta CRL gần đây nhất. Dẫu vậy, cách này cũng sẽ giúp tiết kiệm thời gian và băng thông mạng vì nếu client đã có sẵn base CRL rồi thì nó chỉ cần tải thêm các delta CRL thôi

Vậy có phương thức nào hiệu quả hơn CRL trong việc kiểm tra xem certificate có bị thu hồi chưa không? Câu trả lời đến từ OCSP.

OCSP (Online Certificate Status Protocol)

Như được mô tả trong RFC 2560, OCSP là một giao thức được sử dụng để nhận về trạng thái revocation của một certificate có chuẩn định dạng là X.509. Hoạt động theo mô hình client/server, các thông điệp OCSP (request, response) được mã hóa theo chuẩn ANS.1 và được truyền qua giao thức HTTP. Server cũng thường được gọi là OCSP responder. Cơ bản nó làm việc như sau:

• Client gửi một request chứa serial number của certificate mà nó cần kiểm tra tới server.
• Nếu có sẵn một response được cache cho request trên thì server sẽ gửi ngay cho client. Còn không thì server sẽ kiểm tra xem có sẵn một CRL được cache chưa, nếu có thì nó sẽ dò tìm trong CRL cho serial number của certifcate rồi trả về kết quả cho client. Nếu chưa có file CRL, server sẽ tải về từ các vị trí CDP đã được cấu hình trước.
• Response trả về cho client cho biết 1 trong 3 trạng thái có thể của certificate là:
  • “good”: không có trong CRL
  • “revoked”: bị thu hồi vĩnh viễn hoặc tạm thời (hold)
  • “unknown”: server không biết tới serial number có trong request
• Response cũng được ký số bởi server sử dụng private key của một trong các thành phần:
  • CA đã cấp phát certificate có trong request.
  • Trusted Responder mà public key của nó đã được client tin tưởng
  • CA Designated Responder (Authorized Responder) có certificate được cấp bởi CA mà OCSP server đang phục vụ cho nó.
• Client nhận được kết quả và cache lại để lần sau không cần gửi request lên server để kiểm tra certificate đó nữa.
• Nếu server không thể xử lý request, client sẽ nhận được response không được ký, chứa thông báo lỗi.

Rõ ràng, OCSP đã giải quyết được các vấn đề gặp phải với CRL là:

• Tiết kiệm băng thông do các request và response có kích thước nhỏ hơn nhiều (thường chỉ 4KB) so với file .crl.
• Tiết kiệm thời gian vì chỉ phải kiểm tra trạng thái của 1 certificate thay vì phải phân tích file .crl.
• Nếu thông tin revocation có sẵn trong cache tại client và server thì tiết kiệm được được cả thời gian lẫn băng thông.
• Hệ thống certificate validation với OCSP có thể dễ dàng được mở rộng, độ sẵn sàng cao khi cần xử lý một lượng lớn các request.
• OCSP responder đảm bảo luôn sử dụng các phiên bản CRL mới nhất làm cơ sở cho việc kiểm tra tính hiệu lực của certificate cũng như là khả năng phản hồi gần như lập tức (real-time) khi nó nhận được yêu cầu từ client.
• Một OCSP server có thể phục vụ công tác certificate validation cho nhiều CA. Điều này giúp client tránh phải lưu nhiều CRL.

Tuy nhiên, trong an toàn thông tin thì không có một giải pháp nào giải quyết được mọi khía cạnh rủi ro cả. OCSP không nằm ngoài quy luật đó, nó không phải là “viên đạn bạc” cho vấn đề certificate validation, bản thân nó cũng phải đối mặt với các nguy cơ khác nhau như:

• Availability: Nếu vì lý do nào đó mà client không thể liên lạc với OCSP server thì quá trình validation bị đổ vỡ, khi đó client có thể được cấu hình để quay lại cơ chế CRL.
• Replay attack: kẻ tấn công chụp lại các good response, chờ đến khi certificate bị thu hồi nhưng validity period vẫn còn hiệu lực thì hắn gửi lại response đó cho client.
• DoS/DDoS:  kẻ tấn công cố gắng làm đầy khả năng xử lý của OCSP server bằng cách gửi request với tần suất lớn và liên tục. Việc server phải mất thời gian và năng lực để ký số cho mỗi response cũng khiến tình huống này thêm trầm trọng. Ngoài ra, việc các thông báo lỗi không được ký số cũng bị lợi dụng, kẻ tấn công sẽ gửi các thông báo lỗi giả này cho client và ngăn chặn các good response đến từ server khiến cho client không thể dùng được certificate này.
• Privacy: các thông điệp OCSP đều không được mã hóa nên việc phải gửi request tới OCSP server để kiểm tra certificate cho một domain nào đó khiến bộc lộ địa chỉ IP của client cũng như website mà client muốn ghé thăm.
• Compatibility: Một số ứng dụng và hệ điều hành cũ như Windows XP không hỗ trợ giao thức OCSP.

OCSP stapling
Khi máy chủ web được cấu hình OCSP stapling hoàn chỉnh, đầu tiên máy chủ web sẽ thực hiện truy vấn OCSP đến máy chủ OCSP của CA và lưu trữ kết quả trên bộ nhớ đệm của máy chủ web. Máy chủ web sẽ tự động thực hiện lại quá trình truy vấn OCSP và cập nhật kết quả này sau một khoảng thời gian nhất định. Kết quả truy vấn OCSP này sẽ được được đính kèm trong quá trình thực hiện TLS Handshake giữa trình duyệt và máy chủ web thông qua thuộc tính mở rộng Certificate Status Request. Từ đó trình duyệt có thể sử dụng ngay kết quả kiểm tra tình trạng hợp lệ của chứng thư số SSL mà không cần phải thực hiện truy vấn đến máy chủ OCSP của CA.

Addressing a lot of issues within OCSP, is OCSP Stapling (S. Blake-Wilson, 2006). This TLS-extension allows web services to send a signed response from the OCSP service with the information about the current certificate used. The idea is to let the web service request the status of the current certificate to an OCSP service, and “staple” this signed result to the handshake with the client. The client will be able to verify this OCSP response (because this will be signed by the CA), and use this response to verify that the certificate is not revoked. In this scenario the MitM scenario would not hold up, because the web service is now responsible for serving the correct response. Another important property is the re-use of the OCSP response by the server, possibly cutting down on infrastructure costs (also considering the time interval information prevents a replay attack). By default requiring these OCSP-staples does create availability problems once the OCSP service goes down and the response cached is no longer valid.

OCSP-Stapling also resolves a lot of the privacy implications originally created by OCSP. However, if the amount of OCSP requests based of the server is based on the amount of requests to the server, a CA could still determine if a website is being visited (although visitor numbers should be very low).

OCSP-stapling is implemented on all the popular browsers and web services (Apache, Nginx). Despite the solution that OCSP-Stapling provides there is still a possible attack surface. With a MitM attack, the attacker could still serve a TLS connection, with no OCSP-Stapling extension in the handshake. At this moment all browsers will just verify via CRLs or OCSP, and if the CRLs doesn’t include the certificate and OCSP returns an error (due to infrastructure or the MitM attacker itself) the browser can still consider the certificate valid.


Firefox is trying to (partly) solve this problem by including a header which tells the browser to always requires a OCSP response in the handshake (Keeler, 2013). This is similar to the HTTP Strict Transport Protocol which tells the browser to always enforce HTTPS to a certain domain. Of course these mechanisms requires the browser to have at least visited the website once.

Conclusion and Opinion

Scalability is still a huge problem for managing revocations within an PKI. OCSP tries to improve the efficiency and time inaccuracy of RCLs, but also creates a lot of security issues (confidentiality, integrity and availability). When I was reading the OCSP RFC I kept thinking about these security issues, because these issues have serious implications on the validity of the PKI. I Also was genuinely surprised by the fact that the RFC stated that error messages should not be signed (since this allowed easy denial of service attacks by sending fake responses). Current implementations in web browsers could be considered as messy, since they implement three different kind of revocation checking which are not sound in security as a whole. OCSP-Stapling could be the silver bullet for this problem, but it needs to become required to become security sound. Requiring OCSP-Stapling can however impose serious availability problems once such OCSP systems goes down. I cannot determine if OCSP-Stapling can solve the scalability problem, but seems like a huge step forward compared to the implementation state its currently at.

Source:
https://manthang.wordpress.com/2012/05/04/certificate-validation-crl-ocsp/
https://www.maikel.pro/blog/current-state-certificate-revocation-crls-ocsp/