Deadlock in RAND_poll's Heap32First call
Hi, I had described about the deadlock we are seeing in Heap32First and Heap32Next APIs in my previous post. Here is where you can see the post. http://groups.google.com/group/mailing.openssl.users/browse_thread/thread/3223701a7f64a957/56d67d77c9960429?q=Deadlock+in+RAND_poll%27s+Heap32First+call# Believing that this is a problem with Windows APIs, we raised an incident with Microsoft. MS is still investigating the problem and has asked us to instead use GetProcessHeap and HeapWalk to enumerate the heap entries of the default process heap. Here is what they said Conceptually, the biggest change between using GetProcessHeap/HeapWalk compared to Heap32First/Heap32Next is that you are accessing a heap handle to which you already have access inside of the process – the default process heap. All components are expected to use this heap and it has serialized access to ensure that multiple threads from the same process do not deadlock/corrupt the heap when accessing them simultaneously. Heap32First, on the other hand, accesses all heaps in the process, including private heaps that other components in the process created. Those private heaps might have been created with the HEAP_NO_SERIALIZE option which disallows application requested locking. Components (such as SSIS in your case) typically use this option when they perform the synchronization of memory access on their own to gain efficiency. However, if another component in the process start using those private heaps, it circumvents the synchronization that the component puts in place. And since we lock the heap before reading its contents, the chances of another thread working on the same heap at the same time are nullified. I have made changes to RAND_win.c to use GetProcessHeap and HeapWalk APIs. Would you be interested in accommodating the fix to mainstream code? Please let me know your comments. Thanks, Sandeep
RE: [openssl.org #2417] [Enhancement] X509 verification with OCSP support
Hi Martin,
Sorry for the delayed response. I had developed my own OCSP implementation
external to openssl prior to finding your code in the message archive, so I had
never actually integrated OCSP_check_validity() into your code. While trying
to integrate OCSP_check_validity() into your code this week, I discovered some
fundamental differences:
1) check_ocsp_times() verifies all times within a basic response, while
OCSP_check_validity() only tests a single response's this and next update
fields.
2) check_ocsp_times() utilizes ctx-param-check_time if it is set, while
OCSP_check_validity() does not.
3) check_ocsp_times() sets new, OCSP-specific ctx-error codes in the event
of a an invalid time, while OCSP_check_validity() sets OCSPerr codes (i.e.,
OCSP_R_ERROR_IN_THISUPDATE_FIELD, OCSP_R_STATUS_NOT_YET_VALID).
So in retrospect, it these function aren't a one-for-one swap. The best I
could come up with is inserting OCSP_check_validity() into check_ocsp_times()
inside of check_ocsp_times()'s for(i=0; isk_OCSP_SINGLERESP_num(); i++) loop
to do the thisUpdate/nextUpdate checking. Not the most elegant looking
solution, so I won't post it here.
OCSP_check_validity() still offers the benefit of a skew value, which simply
allows for the OCSP server and OCSP client system clocks to be a slightly out
of sync. Just take a look at ./crypto/ocsp/ocsp_cl.c to see how it works.
The memory fix in get_ocsp() is just 3 lines, as posted in my original email.
Please pardon my manual diffs:
int aiapos, i, ok = 0;
unsigned char *uri;
+ unsigned char* p;
if (!ctx-ocsp_ctx-dl_ocsp)
goto err;
and...
ctx-error = X509_V_ERR_APPLICATION_VERIFICATION;
goto err;
}
+ p = (unsigned char*)data-data;
if (!(aia = d2i_AUTHORITY_INFO_ACCESS(NULL,
- (const unsigned char
**)(data-data),
+ p,
data-length)))
{
ctx-error = X509_V_ERR_APPLICATION_VERIFICATION;
goto err;
Finally, I put the test for id-pkix-ocsp-nocheck in your check_ocsp function:
/* Check if the issuer of the OCSP certificate is the same as of the
* certificate currently checked.
*/
if (!(OCSP_basic_find_signer(ocsp_cert, basic, ctx-untrusted, 0)))
{
ctx-error = X509_V_ERR_OCSP_SIGNING_CERT_NOT_FOUND;
goto end;
}
- if (!(ctx-check_issued(ctx, ocsp_cert, issuer))
+ if (!((ctx-check_issued(ctx, ocsp_cert, issuer)) ||
+ (X509_get_ext_by_NID(ocsp_cert, NID_id_pkix_OCSP_noCheck,
-1
{
/* OCSP certificate could still be one of the authorized
responders */
if (!ctx-ocsp_ctx-auth_responders)
{
ctx-error = X509_V_ERR_OCSP_CERT_ISSUER_NOT_TRUSTED;
goto end;
}
int found = 0, i;
At this point I'm leaning towards my original, external OCSP implementation, as
yours unfortunately was never adopted by openssl. However, I did learn quite a
bit about OCSP by integrating, building and testing your solution.
BTW, my external implementation is based on the code in apps/oscp.c, and it is
tied into openssl's crypto code via X509_STORE_set_verify_cb_func(myStore,
myCb). I then rely on x509_vfy.c's internal_verify() to invoke my myCb
function with ok==1 once per certificate in the chain. My solution does not
have the tight CRL/OCSP coupling that yours has, but as stated before, I won't
be using CRLs.
Thanks again,
- Mike
Michael Siedzik | msied...@enterasys.com
-Original Message-
From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On
Behalf Of Martin Boßlet via RT
Sent: Monday, April 02, 2012 3:08 PM
Cc: openssl-dev@openssl.org
Subject: Re: [openssl.org #2417] [Enhancement] X509 verification with OCSP
support
Am 2. April 2012 17:12 schrieb Siedzik, Michael via RT r...@openssl.org:
Hi Martin,
Did this OCSP enhancement request ever gain any traction? I am adding X.509
support to an embedded system. Due to limited memory, my product is forced
to use OCSP for revocation checking rather than CRLs. This enhancement
should benefit anyone building an embedded system or who would like to use
OCSP for revocation checking.
Hi Michael,
unfortunately I am not aware of any reaction to this request. My goal was to
simplify hooking into the validation process by offering more dedicated
callbacks, making it easier to do online revocation checks with OpenSSL. I'm
glad it turned out to be useful for you!
I have successfully
[openssl.org #2785] Bug RSA x509 key doesn't get generated
I guess I found a bug in openssl 1.0.1 during rsa key generation : openssl req -x509 -newkey rsa:1024 -keyout my.key -nodes -sha1 -days 365 -out my.crt -batch -config /path/to/openssl.cnf This command never ends and returns no error message. It worked fine with openssl 1.0.0 I guess I found a bug in openssl 1.0.1 during rsa key generation :openssl req -x509 -newkey rsa:1024 -keyout my.key -nodes -sha1 -days 365 -out my.crt -batch -config /path/to/openssl.cnfThis command never ends and returns?no error message. It worked fine with openssl 1.0.0
Re: [openssl.org #2778] [BUG:] OpenSSL 1.0.1 x86_64: d1_pkt.c(444): OpenSSL internal error, assertion failed: t = 0
http://cvs.openssl.org/chngview?cn=22334 is interim solution,
proper solution will be provided at later point (if found appropriate).
Thanks, this circumvents the DTLS issue.
The TLS empty fragments issue remains, but this patch hints at
the cause. I think the problem is here, (s3_pkt.c, circa line 664):
if ( (sess == NULL) ||
(s-enc_write_ctx == NULL) ||
(EVP_MD_CTX_md(s-write_hash) == NULL))
clear=1;
if (clear)
mac_size=0;
else
{
mac_size=EVP_MD_CTX_size(s-write_hash);
if (mac_size 0)
goto err;
}
/* 'create_empty_fragment' is true only when this function calls itself */
if (!clear !create_empty_fragment !s-s3-empty_fragment_done)
{
/* countermeasure against known-IV weakness in CBC ciphersuites
* (see http://www.openssl.org/~bodo/tls-cbc.txt) */
... If I'm reading things correctly, the cipher workarounds mean
EVP_MD_CTX_md(s-write_hash) is always NULL so this code skips the
empty fragments countermeasure. Debug printfs verify that clear
differs in good/bad test runs.
I'm guessing this test is here to prevent unwanted empty fragments
before the handshake is complete, but it looks like the logic is
flawed.
I notice similar logic in ssl3_get_record(), (unrelated to empty
fragments). That may be broken also.
Regards,
John
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
