Worldwide LocationsActivIdentity Blog
« Back to Blog HomepageExplaining OCSP through the DigiNotar Attack – ActivIdentity Blog
Author: Ben Erwin, Director of Support, Training, and Technical Publications, ActivIdentity It is not every day that the Online Certificate Status Protocol (OCSP) makes headlines. However, this summer there has been a lot said in security circles about the DigiNotar compromise and how OCSP played a role. On various blogs there is a lot of good information being shared but also some misconceptions about the role of OCSP in the attack. This article talks about OCSP and uses the DigiNotar attack as a concrete example of what OCSP is and how it is used.
Certificate Authority (CA)
A Certificate Authority like DigiNotar is server software that issues digital certificates. In the case of DigiNotar, the certificates that made the news were SSL server certificates which protect secure websites.
In the compromise, hackers were able to issue their own SSL certificates from the DigiNotar CA. Those certificates were used to capture sensitive data from unsuspecting users of sites such as Google’s gmail in Iran. Evidently one of the problems with the security processes at DigiNotar was the use of static passwords. To read more about why static passwords are a bad idea, and why two-factor authentication is a good idea, see http://www.actividentity.com/blog/same-old-static-password-story-is-getting-old.
Certificate Revocation List (CRL)
If a certificate is compromised in some way, the CA operator can add the serial number of the certificate to a “black list” of sorts called the Certificate Revocation List (CRL). New CRLs are published by the CA on a regular schedule chosen by the CA operators such as once every 72 hours or once a week. One of the limitations of CRLs is that they can get rather large depending on the size of the certificate population, leading to latency and bandwidth issues. (There are concepts such as delta CRLs and partitioned/segmented CRLs, but with delta CRLs you still have to have a base CRL, with partitioned CRLs no single CRL can be considered the authoritative source of revocation, and with both delta and partitioned CRLs the relying party (client) and/or CA might not support them.)
In the DigiNotar attack, most of the rogue SSL certificates were discovered by CA operators right away and added to the CRL.
Online Certificate Status Protocol (OCSP)
The Online Certificate Status Protocol (OCSP) is an HTTP-like protocol for being able to securely retrieve the revocation status of one or more certificates rather than download an entire CRL. The OCSP request says “Please give me the revocation status for certificate serial number: 12345” and the OCSP server response is generally “Good” or “Revoked” and the request is signed (I’m simplifying the syntax a bit).
Certificate Revocation List (CRL)
If a certificate is compromised in some way, the CA operator can add the serial number of the certificate to a “black list” of sorts called the Certificate Revocation List (CRL). New CRLs are published by the CA on a regular schedule chosen by the CA operators such as once every 72 hours or once a week. One of the limitations of CRLs is that they can get rather large depending on the size of the certificate population, leading to latency and bandwidth issues. (There are concepts such as delta CRLs and partitioned/segmented CRLs, but with delta CRLs you still have to have a base CRL, with partitioned CRLs no single CRL can be considered the authoritative source of revocation, and with both delta and partitioned CRLs the relying party (client) and/or CA might not support them.)
In the DigiNotar attack, most of the rogue SSL certificates were discovered by CA operators right away and added to the CRL.
Online Certificate Status Protocol (OCSP)
The Online Certificate Status Protocol (OCSP) is an HTTP-like protocol for being able to securely retrieve the revocation status of one or more certificates rather than download an entire CRL. The OCSP request says “Please give me the revocation status for certificate serial number: 12345” and the OCSP server response is generally “Good” or “Revoked” and the request is signed (I’m simplifying the syntax a bit).
An OCSP server will always answer “Revoked” for a certificate that is in the CRL (assuming the OCSP Server has downloaded the latest data)*, and by default it will generally answer “Good” for any serial number that is not in the CRL. If you are familiar with the details of the DigiNotar attack, this might set off your alarm bells. “Wait. What if someone creates a rogue certificate that I haven’t discovered yet? You mean to tell me that the OCSP server will say it is a good certificate?” Yes. Traditional OCSP servers assume that your CA knows what they are doing and have secured their systems. If someone creates a rogue certificate, it won’t be in the CRL until you detect it and manually put it in there, and until that time the OCSP server will say it is a good certificate.
After knowing about the compromise for over a month or so, DigiNotar set their OCSP server to return “revoked” for any “unknown” serial number. However, I am doubtful if any of the rogue certificates would have been considered “unknown” serial numbers to the OCSP server at DigiNotar. If your CA is also your OCSP server, then any certificate that is known to one is likely to be known to the other.
Another limitation of traditional OCSP is that it doesn’t scale very easily. OCSP Responses need to be signed, which means an expensive high-throughput Hardware Security Module (HSM), and there needs to be a database to hold the CRL data. The server itself needs to be secured as well.
Distributed OCSP (D-OCSP)
Distributed OCSP (D-OCSP) is an ActivIdentity/CoreStreet patented invention. With D-OCSP, the OCSP server pre-signs OCSP responses for only the serial numbers that are either in the CRL or are explicitly configure to be “Good” and puts them together in an OCSP Response List. OCSP middle-tier "Responders" consume these pre-signed lists and can then answer OCSP requests. Responders contain no key information and do no signing, so they can be deployed easily and cheaply. Generally they are spread around the globe geographically and products such as F5 BigIP are used to route the OCSP URL contained in your certificate, e.g. ocsp.mycompany.com, to the nearest Responder. D-OCSP thus resolves the scalability issue of traditional OCSP. One can configure the OCSP Server to only pre-generate “good” responses for specific certificates, thus creating a combined “white and black list” of sorts rather than just the “black list” of the CRL data.
Distributed OCSP (D-OCSP)
Distributed OCSP (D-OCSP) is an ActivIdentity/CoreStreet patented invention. With D-OCSP, the OCSP server pre-signs OCSP responses for only the serial numbers that are either in the CRL or are explicitly configure to be “Good” and puts them together in an OCSP Response List. OCSP middle-tier "Responders" consume these pre-signed lists and can then answer OCSP requests. Responders contain no key information and do no signing, so they can be deployed easily and cheaply. Generally they are spread around the globe geographically and products such as F5 BigIP are used to route the OCSP URL contained in your certificate, e.g. ocsp.mycompany.com, to the nearest Responder. D-OCSP thus resolves the scalability issue of traditional OCSP. One can configure the OCSP Server to only pre-generate “good” responses for specific certificates, thus creating a combined “white and black list” of sorts rather than just the “black list” of the CRL data.
Then, at the very least, if hackers get into your CA they would also have to know how to install the certificates that they created into your OCSP Server response list. So in a sense, Distributed OCSP also adds one extra layer which can help protect against the off chance of someone getting a hold of your CA and creating rogue certificates.
More about OCSP
OCSP is generally used by companies and organizations when there is a PKI with at least 1,000 certificates. Not all web browsers use OCSP by default, but many of them do. A lightweight version of the OCSP protocol is also supported by Microsoft in modern operating systems.
An example OCSP server is the ActivIdentity CoreStreet Validation Authority. A company that doesn’t wish to have their own OCSP server can purchase it as a managed service through an ActivIdentity partner.
*If one is worried about the lag time between creation of the CRL and the availability of the OCSP response, the ActivIdentity Smart Data Bridge product can be used to send a message from the CA to the Validation Authority immediately after every single certificate revocation event, and have OCSP available within minutes rather than hours or days.
More about OCSP
OCSP is generally used by companies and organizations when there is a PKI with at least 1,000 certificates. Not all web browsers use OCSP by default, but many of them do. A lightweight version of the OCSP protocol is also supported by Microsoft in modern operating systems.
An example OCSP server is the ActivIdentity CoreStreet Validation Authority. A company that doesn’t wish to have their own OCSP server can purchase it as a managed service through an ActivIdentity partner.
*If one is worried about the lag time between creation of the CRL and the availability of the OCSP response, the ActivIdentity Smart Data Bridge product can be used to send a message from the CA to the Validation Authority immediately after every single certificate revocation event, and have OCSP available within minutes rather than hours or days.
Tags: n/a
Post a Comment
All fields are required.
Legal Disclaimer
Some of the individuals posting to this blog website work for ActivIdentity Corporation ("ActivIdentity"). Opinions expressed in the blog postings and in any corresponding comments are the personal opinions of the original authors, not of ActivIdentity. The blog postings are provided for informational purposes only and are not meant to be an endorsement or representation by ActivIdentity or any other party. This blog website is available to the public. ActivIdentity moderates the comments and comments will not be posted until they are approved by the moderator. ActivIdentity does not guarantee that your comments will be posted to this blog website and ActivIdentity may refuse to post any comments in its sole discretion. No information you consider confidential should be posted to this blog website. By posting comments, you agree to be solely responsible for the content of all information you contribute, link to, or otherwise upload to this blog website. You release ActivIdentity from any liability related to your use of this blog website and the content on this blog website. Your use of this blog website is also subject to the terms and conditions of the ActivIdentity Legal Notice available at http://www.actividentity.com/legal/ (the "Legal Notice"). The blog postings are "materials" and any comments that you post to this blog website are "feedback," each as defined in the Legal Notice.
Some of the individuals posting to this blog website work for ActivIdentity Corporation ("ActivIdentity"). Opinions expressed in the blog postings and in any corresponding comments are the personal opinions of the original authors, not of ActivIdentity. The blog postings are provided for informational purposes only and are not meant to be an endorsement or representation by ActivIdentity or any other party. This blog website is available to the public. ActivIdentity moderates the comments and comments will not be posted until they are approved by the moderator. ActivIdentity does not guarantee that your comments will be posted to this blog website and ActivIdentity may refuse to post any comments in its sole discretion. No information you consider confidential should be posted to this blog website. By posting comments, you agree to be solely responsible for the content of all information you contribute, link to, or otherwise upload to this blog website. You release ActivIdentity from any liability related to your use of this blog website and the content on this blog website. Your use of this blog website is also subject to the terms and conditions of the ActivIdentity Legal Notice available at http://www.actividentity.com/legal/ (the "Legal Notice"). The blog postings are "materials" and any comments that you post to this blog website are "feedback," each as defined in the Legal Notice.
Subscribe to our RSS FeedSearch Blog
Category
Identity & Access ManagementRecent Posts
Recent Comments
Blogroll
The Forrester Blog For Security & Risk ProfessionalsComputer Weekly: David Lacey's IT Security Blog
Infosecurity Magazine: Security Viewpoint
Pro Security Zone: Editor's Blog
IT Pro
Adventures in Security
ha.ckers.org
Information Security: Security Bytes
Krebs on Security
SC: Data Breach Blog
Schneier on Security
Securosis
GovInfoSecurity.com: The Security Scrutinizer
GCN Tech Blog
Cybersecurity
Gartner Blog Network
Cnet: Insecurity Complex
Computerworld: Security Impact Blog
Computerworld: Security is Sexy
eWeek Security Watch
InformationWeek Security Weblog
Network World: Security Strategies Alert
ZDNet.com: Zero Day
Bank Info Security: Industry Insights
Bank Technology News
CRN Community: Hot Topics
Threatpost: Digital Underground