[openssl-users] OCSP_sendreq_bio()

[Walter H.]

On 28.10.2015 18:34, Jakob Bohm wrote:
> On 28/10/2015 17:36, Walter H. wrote:
>> On 28.10.2015 16:44, Jakob Bohm wrote:
>>> On 27/10/2015 21:21, Walter H. wrote:
>>>> On 26.10.2015 21:42, rosect190 at yahoo.com 
>>>> <mailto:rosect190 at yahoo.com> wrote:
>>>>> Hi, I need some help on this call.
>>>>>
>>>>> I am building an OCSP client following guide in openssl and 
>>>>> compile the code in Cygwin environment. My openssl version is 1.0.1h.
>>>>>
>>>>> With HTTP based OCSP, the code works fine. But, with HTTPs, the 
>>>>> code gets stuck at the call to OCSP_sendreq_bio(). Further 
>>>>> debugging shows that OCSP_sendreq_nbio() does not return.
>>>>>
>>>>> Did I need to something extra to deal with HTTPs based connection?
>>>>>
>>>> OCSP must not be https ...
>>>> the same with CRL download ...
>>> Really, I thought that was only a recent cop out rule to
>>> cater to clients with inferior SSL libraries that can't
>>> handle the recursion.
>> both OCSP and CRLs are signed, and this is enough for validation,
>> there is no need of SSL;
> How about privacy.  Especially OCSP queries are very
> revealing, as they indicate the party sending the query
> is using that particular 3rd party certificate at that
> very moment.
>
what would someone really know, if he would catch the OCSP request of 
the attached certificate?
privacy is not really the problem ...

there is one thing that is problematic - especially if the CA is 
somewhat stupid:
using one responder certificate for all OCSP responses for any  end 
entity certificate ...
(the specific RFC says, that it is discouraged to do so)

faking the OCSP response by 3rd party to pretend a good certificate even 
it is bad,
is quite a little bit difficult, but easy if the CA is stupid ...

so it is a bad idea having a OCSP Responder certificate
that was not signed by the CA that has signed the end entitiy certificate

> Only if the SSL certificate for the OCSP or CRL server
> references itself as a way to check for revocation of
> *that* certificate (larger multi-step loops could also
> be built).
>
> However with careful choice/generation of certificates
> for the OCSP/CRL server, this can be easily avoided.
>
easily - are you sure?

example:

(a) you want to check cert 1 that was signed by the CAs cert A
(b) the server uses certificate 2 that was signed by the CAs cert B

with https this would be the following:
to access the CRL or OCSP of cert 1, you need to validate cert 2,
that itself is needed to access the CRL or OCSP of cert 2, too?

do you really think is makes any sense, using https for CRLs download or 
OCSP?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20151028/02e03892/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ssl-cert.pem
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20151028/02e03892/attachment-0001.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4312 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20151028/02e03892/attachment-0001.bin>