Hi Anatol On Mon, Aug 31, 2015 at 10:16 PM, Anatol Belski <anatol....@belski.net> wrote: > > > > > > > There also is an another thing for TS Win build (probably question > > > > for > > > Anatol and > > > > Pierre :) ). The thing is that EVP_SealInit uses internally > RAND_bytes. > > > IIRC there is > > > > some locking issue with openssl RAND on TS win ( the reason why > > > > openssl_random_pseudo_bytes uses Win random) so I was wondering if > > > > it should be disabled on win? The thing is that it is already a case > > > > for > > > other > > > > functions. One example is generating key params in > > > > openssl_pkey_new: > > > > > > > > openssl_pkey_new(array( 'dh'=> array( 'p' => $bin_prime, 'g' => '2' > > > > ))); > > > > > > > > This will also call RAND_bytes when generating priv key. > > > > > > > If you look into crypto/rand/rand_lib.c within the openssl src - it is > > > not thread safe even in 1.0.2 branch. It is a good catch, but has only > > > to do with the thread safety. And the issue is exactly that there is > > > no locking around RAND_bytes() affected codes in PHP. So the issue is > cross > > platform. > > > > > > A quick solution could be using the mutex functionality exported from > > > TSRM > > > (tsrm_mutex_*() functions) in the thread safe builds for affected > functions. > > > > > > > > > > > Yeah I was thinking about that after I sent an email yesterday. I will > check if > > there are more places where this can be an issue and try to put together > a patch. > > > TSRM is probably the best we have in the core right now. Mutex will sure > have a performance impact, but probably no way around it as openssl is > always external. After yet looking at the APIs, maybe one could setup the > default rand in MINIT, or force it to be always RAND_SSLeay(), but not sure > it is a better idea than locking. >
We could maybe set a different RAND method in MINIT using RAND_set_default_method . However this is not recommended as it might be rewritten by the engine API (when/if we add support for loading engines). There also is an alternative way of locking. Rather than use mutex around the function call in openssl.c, we could use CRYPTO_set_locking_callback and register locking there. That should be faster as it locks just places when the race condition can happen. However not sure if that will work for Win as there is some issue with polling entropy as documented in [1] and more info including proposed patch can be found in [2]. I will try to think about it a bit more later to see if I can come up with anything. [1] https://wiki.openssl.org/index.php/Random_Numbers#Windows_Issues [2] https://mta.openssl.org/pipermail/openssl-dev/2015-July/002210.html
