[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


___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Freeing of const char * fields in ASN1_OBJECT

[Reinier Torenbeek]

Hi Michael,

Many thanks for the extensive explanation, I understand the rationale now.

> Now, a *good* public C library will implement proper ADTs.

Indeed I am used to using ADT mechanisms so I did not run into this
issue anywhere else before. It will be a lot of work to make all types
abstracted in OpenSSL... However, as a compromise, I wonder how much
work it would be to at least provide encapsulating allocator/initializer
and free functions for all datatypes. In that case, the const qualifier
for some fields in the struct would make complete sense and the fact
that the const field is allocated/freed by the library is then no longer
anybody else's business.

My problem was indeed resolved by using OBJ_create(), so from now on I
will be looking for creation functions rather than assuming that I am
supposed/allowed to create my own structs directly.

Reinier

PS: apparently there are more reasons to cast away const-ness; I ran
into the following in objects/obj_lib.c:

 65 ASN1_OBJECT *OBJ_dup(const ASN1_OBJECT *o)
 66 {
 67 ASN1_OBJECT *r;
 68 int i;
 69 char *ln=NULL,*sn=NULL;
 70 unsigned char *data=NULL;
 71
 72 if (o == NULL) return(NULL);
 73 if (!(o->flags & ASN1_OBJECT_FLAG_DYNAMIC))
 74 return((ASN1_OBJECT *)o); /* XXX: ugh! Why? What kind of
 75  duplication is this??? */

On 10/28/15 11:02 PM, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
>> Of Reinier Torenbeek
>> Sent: Wednesday, October 28, 2015 16:55
>>
>> In asn1/asn1.h, the fields sn and ln in ASN1_OBJECT are defined as const
>> char *:
>>
>> 211 typedef struct asn1_object_st
>> 212 {
>> 213 const char *sn,*ln;
>> 214 int nid;
>> 215 int length;
>> 216 const unsigned char *data;  /* data remains const after
>> init */
>> 217 int flags;  /* Should we free this one */
>> 218 } ASN1_OBJECT;
>>
>> but in asn1/a_object.c, the get casted to void * and freed:
>> ...
>>
>> Given that a lot of the code is supposed to be self-describing (due to
>> lack of documentation), it is somewhat disturbing that I can not rely on
>> the const qualifiers to be honored. Any thoughts on this?
> It's a well-known problem with the semantics of const in C.
>
> The parameter to free() cannot have the const qualifier, because the 
> semantics of free say that the object referred to by the pointer reaches the 
> end of its lifetime during the call to free(), and attempting to use it after 
> that results in Undefined Behavior.
>
> However, it is perfectly reasonable to want to allocate storage, initialize 
> (and even alter) its contents, but have that object treated only as an rvalue 
> elsewhere. This is a very typical use case for a library or other code that 
> presents an ADT (abstract data type) to a caller.
>
> The mechanism for informing a caller that an object should not be modified is 
> the const qualifier.
>
> There are only two ways around this problem. One is for the ADT 
> implementation to keep both a const and a non-const pointer to the same area, 
> publish the const one, and use the non-const one for freeing. That's a rather 
> absurd duplication of effort (and a small amount of storage) just to account 
> for C's simplistic const/free semantics.
>
> The other way, which is the one everyone uses, is to cast away the constness 
> of the pointer when passing it to free.
>
> Note that the problem arises in other contexts. That's why C++ has a category 
> of casts just for this purpose (casting away constness). Another case you 
> often see is a function in an external library that never modifies the object 
> pointed to by a parameter, but failed to declare it as const (generally 
> because it was written by someone who doesn't understand C, which is to say 
> ~97% of all C programmers).
>
> As a rule of thumb, when a function parameter itself is a pointer to a 
> const-qualified object type (this doesn't apply to const pointers to 
> non-const objects), you should be able to assume that the function does not 
> change the object. When a function parameter is a pointer to a 
> non-const-qualified aggregate type (struct or union) that happens to include 
> const-qualified members, do NOT assume that there are no cases in which those 
> objects are modified. You really have to check the implementation of that 
> function.
>
> C function contracts are weak.
>
> Now, a *good* public C library will implement proper ADTs. It will define 
> them as pointers to incomplete structures, so you can't go poking around 
> inside them; it will give you construction and cleanup functions; and it will 
> give you accessor functions. Some people will complain that at that point 
> you're no longer writing C - you're reinventing C++ - to which I'd reply that 
> they don't really understand C or C++.
>

Re: [openssl-users] OCSP_sendreq_bio()

[Jakob Bohm]

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, rosect...@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