Hi Chris,
On 19/08/2010 21:40, chris.g...@k-embedded-java.com wrote:
Hi Oliver,
- Set a single global set of native RNG callback functions that then
figures out (somehow) who made the original call into the OpenSSL
natives and uses the appropriate SecureRandom implementation. This
would be tricky, but might be possible. I imagine we could look up the
stack for the last Java (i.e. non-native) frame and could get the
SecureRandom reference from that class.
I went for something like this option in the end using ThreadLocals to
get back my SSLParameters class when we're in the RNG functions (thanks
to Cath Hope for this idea!). I'm not completely satisfied with the
solution, but it works and is fairly simple. In the case where no
SecureRandom implementation is provided the code falls back to the
OpenSSL default RNG functions.
The only problem I see with this is that it assumes that all calls to a
particular SSL engine instance will be made from a single thread.
I think the solution I've implemented should work in multiple threads as
well. It follows these steps:
- when a thread is about to make a native call that will call OpenSSL
it sets a thread local with its SSLParameters instance. This means that
even if multiple threads share the same SSL engine and SSLParameters
they will each set their own thread local containing the correct
SecureRandom instance to use.
- the natives do whatever they need to. If the RNG functions are
called they lookup the thread local set in the first step and use the
SecureRandom implementation if it is set. If no SecureRandom has been
set, the code falls back to calling the OpenSSL default RNG.
- when the natives have returned, the thread removes its thread local
and continues.
This should mean that each thread has its own thread local correctly set
whenever we are in OpenSSL calls (at least those calls that might use
RNG functions).
That may
not be the case if for example the SSL connection is established by a
"main" or "startup" thread and then messages will be sent on that
connection by an EventListener which is run by a quite different thread.
That would lead to extremely puzzling bugs 8-0. From that point of view I
would prefer an implementation which simply ignored the user-supplied
SecureRandom (and clearly documented this behaviour).
Yep, and I agree in that case, but I think the solution I have should
work in multiple threads so hopefully we can satisfy the spec.
I also have to say that if this is the biggest unsolved problem you still
have, I'm pretty impressed.
It may be that I just haven't discovered the biggest problem yet ;)
Regards,
Oliver
Best regards
Chris Gray
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
