Btw let me know if I can ever be of help. Ryan Hurst Chief Technology Officer GMO Globalsign
twitter: @rmhrisk email: ryan.hu...@globalsign.com phone: 206-650-7926 Sent from my phone, please forgive the brevity. On Jun 14, 2013, at 3:09 PM, Jakob Bohm <jb-open...@wisemo.com> wrote: > On 6/13/2013 1:50 AM, Ryan Hurst wrote: >> They are doing a CA signed OCSP response, this is legitimate. >> >> We will do this in the not so distant future as well for many of our >> responses also. > > Please don't! > > As a knowledgeable GlobalSign customer I would prefer that you keep your root > private keys as secure as possible. > > Using CA signed OCSP responses implies some serious and almost > impossible to mitigate security risks: > > -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > For a "CRL-style" CA signed OCSP responder: > > - I define this as an OCSP responder that returns ONLY pregenerated > responses, which it receives a a regular batch of responses for all > issued certificates from the offline CA. > > 1. The short validity times expected by OCSP clients requires that new > response batches are created 100 times per day or more, while the need > to remain compatible with older (RFC2560) clients requires each > response in the batch to cover only one certificate. Together, these > two factors provides attackers with an easily collected collection of > millions of signatures on algorithmically predictable data issued by > the root key. This is exactly the kind of data needed for most > otherwise infeasible/theoretical attacks on a public/private key pair. > > 2. The only way to make the signed data in a pregenerated OCSP response > unpredictable is to include a random salt in a non-standard extension > in each response. To avoid leaking the state of the internal RNG of > the CA's HSM, such salt must be generated by a trusted RNG unrelated > to the one in the primary HSM. > > 3. Due to shortcomings of the OCSP protocol documents, response batches > can only be pregenerated ahead of time by including false time > information in them, (lack of clarity means that some clients might > reject producedAt values before thisUpdate) at best one could use the > CRL reference extension to indicate the true generation time, but only > if a real CRL is also generated as part of the batch. This makes it > hard to take the root key holding HSM temporarily offline for security > issues or any other good reason. This issue persists in RFC6960. > > 4. Due to shortcomings and lack of foresight in the OCSP protocol > documents, the generation and return of responses using the SHA-1 hash > algorithm will probably remain necessary at least until June 2021 (the > 10 year anniversary of RFC6277), and responses using the SHA-256 hash > algorithm until an unknown date after the year 2023 (since no RFC has > yet been issued specifying any other must-accept algorithms). > > Furthermore, there are no must-accept algorithms using any > contemporary version of DSA, nor using any algorithms not from the > NSA-designed MD4-derived old SHA algorithms. There is not even a > requirement that clients must accept the algorithm used to sign the > certificate being checked. This issue persists in RFC6960. > > 5. There is no feasible way to pregenerate negative responses for never- > issued certificates. Most notably, such negative responses cannot > cover a range of unissued serial numbers and standard practice uses > serial numbers so long that it is virtually impossible to even store > one bit of response data for each unused serial number, let alone > transmit such responses. The closest potential solution would be to > use a streaming algorithm to generate but not store a sequence of > SingleResponse for all serial numbers from X to Y, compute and store > the surrounding parts of a BasicOCSPResponse holding that sequence, > then recreate it on the fly when sending this response to a requestor, > however the transmission bandwidth of such a monster response would > still be prohibitive. This issue is present in RFC6960. > > 6. A "CRL-style" CA signed OCSP responder cannot respond to requests > covering more than one certificate, since doing so requires the > generation and storage of responses for almost infinitely many sets > of certificates. If the client implements RFC6960, it is possible to > simply send back a pre-signed response which is essentially the entire > CRL in a different format, however the protocol does not provide this > information in the Request, so this cannot be done until June 2023 (10 > year anniversary of RFC6960). > > -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > For a truly online CA-signed OCSP responder, things are even worse: > > - I define this as an OCSP responder which generates responses on the > fly and signs them with the CA root key. > > 1. It requires the CA root key to be available to at least one system > (HSM or otherwise) with access to the CA private key to be online in > a manner which completely prevents human vetting of requests (because > the root key must be used at very short notice 24x7). This provides > an avenue for seriously motivated attackers to work their way through > all the security layers one by one until they reach the private key. > > The GlobalSign root keys are such valuable targets to both criminal > and rogue government government groups that a STYX style operation to > capture them must always be expected. > > 2. It requires the HSM storing the root key to never be offline, at > all. This makes it impossible to take the root key holding HSM > temporarily offline for security issues or any other good reason. > > 3. Due to shortcomings and lack of foresight in the OCSP protocol > documents, the generation and return of responses using the SHA-1 hash > algorithm will probably remain necessary at least until June 2021 (the > 10 year anniversary of RFC6277), and responses using the SHA-256 hash > algorithm until an unknown date after the year 2023 (since no RFC has > yet been issued specifying any other must-accept algorithms). > > Furthermore, there are no must-accept algorithms using any > contemporary version of DSA, nor using any algorithms not from the > NSA-designed MD4-derived old SHA family. There is not even a > requirement that clients must accept the algorithm used to sign the > certificate being checked. This issue persists in RFC6960. > > 4. It allows, by design, anonymous remote users to request a huge > number of sample signatures made with the root private key, which is > exactly the unobtainable part of many known theoretical attacks, and > this is likely to be the case of many yet-to-be known future attacks. > > The standard countermeasures against such attacks are likely to be > ineffective in the case of a high profile OCSP responder: > > 4.1 Limiting the request rate to a safe value is not possible, an OCSP > responder for a large CA must by definition process millions of > requests per week, each with subsecond response time. > > 4.2 Watching for suspect request patterns and taking the system > offline until the attack fades away. Taking an OCSP responder offline > for even a few minutes will have devastating consequences that > preclude taking such measures on a mere suspicion (and when it is no > longer just a suspicion, it is probably too late). > > 4.3 Blocking IPs that issue suspiciously many requests will be > ineffective (because anyone going after such a high value target is > likely to use botnets or other request IP scattering techniques), and > counterproductive (because it will most likely detect and falsely > block major proxies, online virus scanning services etc.). > > 4.4 Salting the responses with random or other attacker-uncontrolled > data requires the ability to know which aspects of such salting will > prevent which attacks. And high profile CAs need to be prepared for > unknown attacks on their private key. Random salts also provide > attackers with excellent insights into the RNG employed, thus any > security weakness in the RNG design (even if it is backed by a true > quantum phenomenon hardware RNG) can be more readily exploited by > attackers. > > 4.5 Rejecting requests for the status of never issued certificates at > a front end without (indirect) root key access may reduce the > attackers flexibility in choosing data to be signed, but there are > still plenty of issued certificates that can be harvested from public > certificate uses, collated and sorted on their bit patterns relative > to the needs of the attempted attack. > > 4.6 Caching responses, so each certificate only gets a freshly signed > OCSP response once every few minutes, severely limits the ability of > OCSP clients to verify that the response is current, and cannot cope > with some of the protocol requirements (request nonces, multiple > certificates in one request, negative responses for never issued > certificates), while still providing lots of data (100.000 unique > signatures per issued cert per year of validity if you cache each > response for 5 minutes). And note that the attacker will have the > full root cert lifetime to gather up sample responses for input to his > cryptanalysis. > > -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Contrast this with the security properties of a delegated OCSP > responder: > > 1. Delegated OCSP signing certs can be routinely revoked and replaced > as often as needed (you will need to set up a second OCSP responder > URL, with each URL the sole source of OCSP checking of certificates > issued to responders at the other URL). > > 2. Spare and backup responders can be prepared, complete with their own > private keys and certificates ahead of time. > > 3. Because their hardware lifetime is not tied to the (old) HSM holding > a 30+ year key, delegated OCSP responders can deploy new security > measures without having to work around hardware limitations of the > existing HSMs used. In fact, even if no HSM implementations of a new > security measure are available, an ordinary server with an ultra- > short-lifespan OCSP-responder certificate can do the job with little > overall risk until a more robust implementation is available. > > 4. Because there is no requirement that all responses are signed with > the same key, delegated OCSP responders can be set up as redundant > systems with multiple servers and sites handling the same OCSP URL, > allowing maintenance to be done without taking all the clients offline. > > 5. In case of non-compromised root key loss (imagine if the root key > facility had been in in Dresden last week or New York during Sandy or > the 2001 attack), a delegated OCSP responder with a pre-issued > non-expiring certificate can continue to serve customers while a new > root key is brought online, deployed into browser trust stores and > finally used to issue new replacement certificates. For good measure, > supplement with a set of similar delegated CRL signing certs, although > I suspect the latter would not be usable with many existing clients. > > 6. In case of root key compromise, a handful of almost-never-expiring > OCSP certificates can be pregenerated and stored at secure off-site > locations. In case of disaster, these can be installed on OCSP > servers that return "key compromise, certificate revoked" for all > requests that mention the lost CA. These (along with pre-signed > non-expiring revoke-all CRLs) can be used even if access to the > compromised root private key was lost in the disaster, e.g. due to > a too late triggering of a self-destruct mechanisms. Remember to not > use all the pre-issued OCSP certificates at once, hold some of them > back in case the online ones are compromised. > > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com > Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org
smime.p7s
Description: S/MIME cryptographic signature
