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. 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). I also have to say that if this is the biggest unsolved problem you still have, I'm pretty impressed. Best regards Chris Gray
