harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: [classlib][x-net] Creating a provider based on OpenSSL
Date Fri, 20 Aug 2010 10:12:23 GMT
  Hi Chris,

On 19/08/2010 21:40, chris.gray@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


Mime
View raw message