[openssl-users] OCSP_sendreq_bio()

[Jakob Bohm]

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 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.

If the generals computer requests OCSP validation for
weather.com, followed by OCSP validation for a service
that reports sunrise/sunset, followed by OCSP validation
for the e-mail certificates of his top lieutenants, this
is as revealing as if he had sent the message "attack at
dawn" in the clear.

> and an infinite recursion would be implied because of
> the need of validating these SSL-certificates the same way
> as the origin SSL-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.

> but be aware the CRLs can be in an LDAP - done by bad CAs;
> OCSP must be HTTP
I have mostly seen that for site-local CAs that already
integrate all their other work with the same LDAP
servers.  I guess it could also be done by genuine
X.500 directory systems as originally envisioned by the
ITU (i.e. publishing the actual public phone book via DAP
or LDAP, with distinguished names representing their
originally intended phone book fields and certificates
issued to phone line subscribes according to the usual
telephone network hierarchy, CN=US,ST=CA,C=Klondyke,...
Serial=1-555-555-5555),



Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20151028/81e8e475/attachment-0001.html>