Friday, October 23, 2009
Defeating OCSP – is it that ez?
Certificates in the scope of asymmetric cryptography are an approved means to achieve a solid state of security in many applications (using TLS/SSL predominantly). Options in this area of computer security are limited. Establishing trust and running a CA (Certificate Authority) is cumbersome and need a lot of resources. A widespread usage of certificates comes along with a higher number of revoked certificates that must be identified in order to deny access. Certificate revocation lists (CRL) and the OCSP (Online Certificate Status Protocol) are options to establish these check points. To keep CRL’s up-to-date and to handle their constant growth, is a well-known problem. OCSP provides this status on a server in a centralized approach. A check point (server, client, any consumer of a certificate) can ask the OCSP-server in order to make sure that the presented certificate is not revoked. But can we trust the response? Not in any case as we could learn from a security expert recently (check on heise security and other resources). ResponseData and ResponseStatus are different structures within the response but only ResponseData is covered by a signature. A faked response (by a running a man-in-the middle attack) could send a “tryLater” which is a valid status. It’s up the OCSP-implementation at the check point to handle this response properly. And. it’s up to you to imagine how this is handled in a real-world implementation. It’s a kinda scary if you can’t even trust a security service indented to provide “more security”.