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