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
