[openssl-users] OCSP_sendreq_bio()

Thu Oct 29 10:07:58 UTC 2015

On 28/10/2015 21:58, Walter H. wrote:
> 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 ...
>
She (Eve) would know that the requesting party Alice
was talking to Bob at the very moment she sent Trent
the OCSP *request* for Bob's certificate.

And by just listening to that one address (the
unencrypted requests being sent to OCSP responder
Trent), Eve would essentially get the Internet
equivalent of having (almost complete) real time
copies of everybody's phone bill/call records.
Who was calling who at what time.

That's very valuable private information which Eve
could otherwise get only by monitoring traffic at
thousands of Internet routers.

And as an added bonus, she gets to see when Alice is
reading e-mails signed by Bob (because Alice's e-mail
program would make an OCSP request when it checks the
signature as she opens the mail that is already stored
behind Alice's high strength firewall.

With https-encrypted OCSP transactions, all she can
see is that Alice is doing *something* that involves
checking *some* *unknown* certificate issued by Trent.
Only Alice and Trent would know which one.

With https-encrypted CRL requests, Eve can see much less,
as all she will know is the first time in each CRL-period
Alice is checking some Trent-issued certificate, and perhaps
even less if Trent has other popular data on that https
server or Alice's computer downloads the CRLs for trusted
CAs on a schedule regardless if Alice is even in the
building.  If Trent is a provider of Antivirus, a popular
video download site or anything else that responds to
millions of other https downloads unrelated to interesting
activity, putting the CRLs on that same server will make
even this information near impossible to observe.

CRLs over http reveals the CRL access information with
more accuracy as it cannot get hidden in a flux of other
requests.

On the authenticity side, using https provides a direct
proof that non only is the validity information not
stale (past its end date), but it is the most recent the
server had at the time of the request, not slightly older
information provided by an active attacker who wants to
use a compromised certificate a little bit longer than the
time it takes the CA to revoke it.  For OCSP that could
alternatively be achieved without the other benefits by
using the nonce option in the OCSP request, but this
alternative would not solve the other problems and
wouldn't work for CRLs.

> 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)
This is not about the OCSP-response signing certificate
(or the CRL signing certificate).  Those are unavoidable
and have already established practices for avoiding the
chicken/egg problem of revocation checking.

It is about the https SSL certificate of the web server
that provides access to the OCSP-response service and/or
the CRL download service.
>
> 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?
>
As I said it involves recursion and the trick is to
terminate that recursion before it gets infinitely
deep.

One obvious way is that at some (not too deep) level
of recursion, the certificate to be checked (whose
private key is that of a trusted CA-owned machine
anyway) doesn't specify an OCSP responder or a
https CRL URL, just like the rules that already
govern the revocation checking extensions in OCSP-
signing and CRL-signing certificates.

And the checking of that shared deep-level CA-owned
certificate is a lot less revealing of Alice's
activity than the checking of a specific certificate
related to Alice's current non-protocol activity.

Another obvious way would be for that final https
server to do OCSP-stapling, thus terminating the
recursion for any relying party (Alice) whose
client software knows how to parse and validate
OCSP-stapled validity proofs.

> do you really think is makes any sense, using https for CRLs download 
> or OCSP?
>
See my longer response above about the specific security
dangers inherent in using plain http for OCSP and (to a
lesser degree) CRLs.

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/20151029/f1cdf55d/attachment.html>