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 Thu, 19 Aug 2010 07:59:02 GMT
  On 16/08/2010 13:47, Oliver Deakin wrote:
>  I've been making steady progress with this implementation so far but 
> I've hit a snag. The Java spec allows users to specify a SecureRandom 
> implementation when creating connections, and there can be different 
> SecureRandom implementations for different connections in the same VM 
> instance. However, OpenSSL only allows one global random number 
> generator (RNG) to be specified. This means that currently there is no 
> way to fully satisfy the Java spec. I see 3 options for implementing 
> this:
>
>  - Implement the additional APIs to do this in OpenSSL ourselves or 
> ask the OpenSSL project to do it. I'm not sure if there is much need 
> for this from OpenSSL's point of view so I don't think this is a very 
> good option.
> - 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.

Regards,
Oliver

> - We just ignore the SecureRandom class passed in by the user or only 
> use one of the specified implementations. This would be a departure 
> from the spec but in practise should not make any difference to the 
> security of the connection. I think it would be unlikely that users 
> would specify multiple different SecureRandom implementations (or 
> specify any at all in most cases), so this may be a reasonable solution.
>
> I'm going to investigate the 2nd option as I think this offers us a 
> way to satisfy the spec without modifying OpenSSL and allowing us to 
> work with previous versions also.
>
> Any thoughts/comments?
>
> Regards,
> Oliver
>
> On 02/08/2010 11:08, Oliver Deakin wrote:
>> <SNIP>
>>
>> Regards,
>> Oliver
>>
>> [1] https://svn.apache.org/repos/asf/harmony/enhanced/java/branches/omd
>>
>> On 19/07/2010 17:15, Oliver Deakin wrote:
>>>  Hi all,
>>>
>>> I'm currently investigating the possibility of implementing a JSSE 
>>> provider wrapping OpenSSL. This has a couple of obvious advantages:
>>>  - The onus of code maintenance and bug fixing in a security 
>>> sensitive area is moved outside of Harmony.
>>>  - New protocols can be integrated into the Harmony provider with 
>>> minimal effort (updating dependencies rather than implementing them 
>>> ourselves).
>>>
>>> Really I'm sending this mail as a heads up, but would be interested 
>>> to know if anyone has any experience/opinions in this area. In 
>>> particular, I'd be interested in ideas on:
>>>  - the best way to setup OpenSSL as a dependency - precompile the 
>>> libraries and make them available for download or compile them at 
>>> build time on the user's machine.
>>>  - how to tie in the Java x-net APIs to the OpenSSL APIs.
>>>
>>> Any comments/suggestions welcome.
>>>
>>> Regards,
>>> Oliver
>>>
>>
>

-- 
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