Is it me or is ocsp.comodoca.com doing something wrong?

[Igor Sverkos]

Hi,

I tried to validate a certificate from Comodo using their OCSP, but I
cannot verify the response:

3073455752:error:27069076:OCSP routines:OCSP_basic_verify:signer
certificate not found:ocsp_vfy.c:85:


The certificate I want to validate was issued by

C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO
High-Assurance Secure Server CA

The cert chain is:
0: <The certificate I want to validate>
1: COMODO High-Assurance Secure Server CA
2: AddTrust External CA Root (aka USERTrust)

My steps:
1) # wget -O level1.pem
"https://support.comodo.com/index.php?dload=Download&_m=downloads&_a=downloadfile&downloaditemid=101"


2) Verifying the level1.pem certificate (COMODO High-Assurance Secure
Server CA), this check will also make sure, that the root certificate
(level2) is present on my system:

# openssl verify -CApath /etc/ssl/certs/ level1.pem
level1.pem: OK


3) Now I created the OCSP request:

# openssl ocsp -CApath /etc/ssl/certs -CAfile level1.crt \
-issuer level1.crt -cert level0.crt \
-url http://ocsp.comodoca.com \
-reqout request.der

To share it with you, I called base64 on request.der:

# base64 request.der
MHYwdDBNMEswSTAJBgUrDgMCGgUABBT950qEosxt1h7EdDv7v4q+SjikWAQUP9W10NZEeVBKF6Ob
jErcuLAiZGsCEExO1VM4XfiatpW5unQb4gOiIzAhMB8GCSsGAQUFBzABAgQSBBAo6nzdxvtLR5Gi
hO44WuHv

So you can grab the response from
<http://ocsp.comodoca.com/MHYwdDBNMEswSTAJBgUrDgMCGgUABBT950qEosxt1h7EdDv7v4q+SjikWAQUP9W10NZEeVBKF6ObjErcuLAiZGsCEExO1VM4XfiatpW5unQb4gOiIzAhMB8GCSsGAQUFBzABAgQSBBAo6nzdxvtLR5GihO44WuHv>



When I compare against responses from ocsp.verisign.com or
ocsp.globalsign.com I am missing the OCSP responder certificate in the
response.


So my question is:
1) Is it ok, what Comodo is doing here?

2) If it is OK, how can I be sure, that the response is from a valid
source, when I cannot validate (=or how can I validate this
certificate/response)?

Thanks.


/etc/ssl/certs is from ca-certificates package (20130119)
I am using OpenSSL 1.0.1e 11 Feb 2013


--
Regards,
Igor
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org

[Ryan Hurst]

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.

You basically need to look at the responderID and see if it's the same
entity that signed the certificate you are checking if so use that key
material to do the validation.

Ryan

MHYwdDBNMEswSTAJBgUrDgMCGgUABBT950qEosxt1h7EdDv7v4q+F6Ob

[Igor Sverkos]

Hi,

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.

If this is called "CA signed OCSP response", how is *your* current
response, which you will change in future, called?

> You basically need to look at the responderID and see if it's the same
> entity that signed the certificate you are checking if so use that key
> material to do the validation.

Mh...

The responderID is "3FD5B5D0D64479504A17A39B8C4ADCB8B022646B".

I don't know how to check it. Can somebody help?

I sha1sum'ed the fingerprint, issuer and subject of level1 (COMODO
High-Assurance Secure Server CA) and level2 (AddTrust External CA
Root) but I did not find such a hash/value.

For me it looks like they are using some kind of delegated OCSP
signer, but because they did not include the signer's certificate in
the response like other OCSP are currntly doing, I am unable to verify
(like openssl's binary), because I don't have the signer certificate.
But how should I get it?

But maybe I am totally wrong... I am new to this, sorry.

Thanks.

[Igor Sverkos]

Hi,

forget it - I got it :)

"-VAfile level1.crt" is doing 'the trick'.

But I still don't now how to compute/get the responseID on my own.

[Jakob Bohm]

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

[Ryan Hurst]

Jakob,

Online CA signing keys for something like OCSP signing is a bad idea and
don't worry we wont do that; we are looking at doing is using pre-produced
OCSP for issuing CAs issued certificates; in this model all cache-misses and
root responses would be VA delegated still.

This protects the CA key material yet keeps the large majority of the
responses much smaller due to the left out keys.

For this to be a viable model, as you point out frequency of response
generation is one factor, as is the validity period of the issuing CA.

CAs are required to produce responses every 7 days, we comply with that but
as part of our new infrastructure investment we will be bringing that time
down quite a bit; the largest issue here being time skew on the broader
internet. This introduces practical limits that mean that you cant be "too
fresh" on your revocation times.

It also means producing fresher responses 100s of times a day isn't of much
value, you can of course update the changes in the cached responses set to
be accurate but fresher / shorter lived responses end up breaking things for
a reasonably large % of users.

I believe this approach addresses most of the concerns you mentioned
bellow, a few exceptions:

You state that pre-produced OCSP responses cant span multiple certids
(practically), while this is true we receive exactly zero such requests to
do and testing shows that major clients don't even handle the case correctly
when such responses are returned (geotrust does this); they simply store the
larger response many times even if they already had a signed response that
was valid covering that certid.

Ryan

-----Original Message-----
From: owner-ope...@openssl.org

[Jakob Bohm]

On 6/15/2013 1:15 AM, Ryan Hurst wrote:

Thanks for your reply, just one tidbit that surprised me:

>
> CAs are required to produce responses every 7 days, we comply with that but
> as part of our new infrastructure investment we will be bringing that time
> down quite a bit; the largest issue here being time skew on the broader
> internet. This introduces practical limits that mean that you cant be "too
> fresh" on your revocation times.
>
> It also means producing fresher responses 100s of times a day isn't of much
> value, you can of course update the changes in the cached responses set to
> be accurate but fresher / shorter lived responses end up breaking things for
> a reasonably large % of users.
>

Ahh, I never heard about this 7 day rule, the closest I had previously
heard was a CSP for a (now essentially defunct) national CA, which
required CRL update delays of 1 minute or less from compromise reports,
and those were not even qualified certs!

From this I kind of surmised that OCSP validity times > 5 minutes would
be as unsupported as DNS TTLs > 1 month.

> I believe this approach addresses most of the concerns you mentioned
> bellow, a few exceptions:
>

> ...

You missed another concern: The need to use old dubious signature
algorithms for the next 10 years, due to the late publication of
RFC6277, the failure to require in the spec that clients must
accept the alg used to sign the cert and the failure of even the
latest RFC6960 to specify anything other than SHA-1 and SHA-256, and
the failure to provide any request indication that a client
implements anything post-RFC2560 (you could be lucky to receive
a redundant algorithm list specifying the defaults from some post
RFC6277 clients).

[Ryan Hurst]

I agree 2560's lack of algorithm agility is a problem and RFC6960's lack of
specifying an indicator of which algorithm to use is also a little
problematic; that said it is one that can be worked around in most cases.

One likely way is that responders will rely on the User Agent header to
determine platform support for a given behavior and if algorithm support
isn't explicitly known fallback to SHA1; this can help accelerate the
adoption of SHA2 in OCSP but the larger platform adoption problem still
exists.

It takes roughly 10 years from release of Windows to 98% ubiquity; that mean
we better hope Windows adds support for RFC6960 soon so that clock can start
ticking.

Has support been added to OpenSSL yet?

-----Original Message-----
From: owner-ope...@openssl.org
[mailto:owner-ope...@openssl.org] On Behalf Of Jakob Bohm
Sent: Friday, June 14, 2013 5:00 PM
To: openss...@openssl.org
Subject: Re: Why CA-signed OCSP responders are a bad idea [WAS:Is it me or
is ocsp.comodoca.com doing something wrong?]