[openssl-users] Thoughts about security, privacy, ... (was: OCSP_sendreq_bio())

[Walter H.]

Hello Jabob,

On Thu, October 29, 2015 11:07, Jakob Bohm wrote:
> 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:

>>>>>> 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.
>
> [...] equivalent of having (almost complete) real time
> copies of everybody's phone bill/call records.
> Who was calling who at what time.

this is not a problem as long as the public keys (the certificates) are
not really public;
because in your example Eve doesn't have the knowledge which certificate
the specific serial number has ...

if the public keys (the certificates) are searchable by public - the worst
case direct by a search engine like google - then you would get an
absolute security whole:
think of some bad boys, they could get such certificates and get two
things with these: a valid e-mail address and everything they need to send
encrypted data to this e-mail address, and with this: they can send
anything: malware, spyware, whatever; no antivirus, spamfilter, or
whatever on any mailserver would stop such emails; everything hangs on the
client ...

the scenario you gave above is the less 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)
> This is not about the OCSP-response signing certificate
> (or the CRL signing certificate).
No it is about them ...
https://www.rfc-editor.org/rfc/pdfrfc/rfc6960.txt.pdf (stupid CAs
- I know at least one - ignore the section on top of page 17)
with such CAs it is easy to pretend something different ...

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

it is more a deadlock than a recursion ...

> Another obvious way would be for that final https
> server to do OCSP-stapling,

this would be a solution but as soon as using SSL/TLS layer communication
for CRL download or OCSP, for whatever reason, accepting OCSP-stapling is
strongly discouraged, this is nearly like self-signed ...

I'd say security is more important privacy;

Greetings,
Walter