Sorry, I am posting to tomcat-dev although not subscribed...
Two suggestions:
- Perhaps it is a good idea to also describe in the SSL HOWTO ways to
configure SSL without stuffing libs into jre/lib/ext. Some sites run
multiple versions/vendors of jdks, TC, JSSE, et al from (secure) read-only
shared file systems. In such an environment products and versions are
delibarately kept separate from each other in order to avoid having to
maintain countless permutations. Startup scripts "link" everything together
via env vars. This is also convenient to test different permutations. The
jre/lib/ext mechanism is not an option, due too the read-only nature.
- The other point: I recall a discussion some time ago about the sluggish
performance of session id generation and the idea of using /dev/random to
speed this up. The cryptix JCE CryptixRandom provider can be useful here
(see below a conversation with a sun security engineer).
Wolfgang.
>Brad, thanks for the *fast* reponse.
>
>The point is that developing an application has to make sense in the first
>place.
>10 secs SecureRandom start up time for client side command line apps means
>that such an app will never be used.
>If an application is never used it is irrelevant how secure it is, except
>for academic discourse.
>0.5 secs is the pain limit for client side command line apps.
>Plus, /dev/random is more than secure enough for many apps.
>
>Just for the record, with the help of the cryptix JCE CryptixRandom
>provider (www.cryptix.org) I finally figured out how to do this
>effectively. Perhaps others may find the solution helpful as well:
>
>java.security.Security.insertProviderAt(
> (java.security.Provider)
> Class.forName("cryptix.jce.provider.CryptixRandom").newInstance(), 1);
>java.security.Security.addProvider(
> ((java.security.Provider)
> Class.forName("com.sun.net.ssl.internal.ssl.Provider").newInstance()));
>com.sun.net.ssl.SSLContext ctx =
>com.sun.net.ssl.SSLContext.getInstance("SSL"); // JSSE 1.0.2
>//javax.net.ssl.SSLContext ctx =
>javax.net.ssl.SSLContext.getInstance("SSL"); // JDK 1.4
>ctx.init(null, null, java.security.SecureRandom.getInstance("DevRandom"));
>factory = ctx.getSocketFactory();
>sock = factory.getSocket(...)
>
>Now on a 2x600 Mhz PentiumIII, Linux
>
>ctx.init() takes 0.2 secs using the /dev/random algo (compared to 10 secs
>using the default SecureRandom algo).
>
>Cheers,
>Wolfgang.
>
> >com.sun.net.ssl.SSLContext.getInstance("SSL").init(null, null, new
> >java.security.SecureRandom(new byte [] {25,13,32,5}));
> >
> >to no effect. Perhaps I need to store the SSLContext somewhere. If so,
> where?
>
>Again, doing anything like you describe with Random or preseeding with
>a fixed byte array is a *VERY BAD* idea in a production system. It's
>ok for testing, but you'll seriously limit your security
>effectiveness. I can't stress this enough.
>
>As to your immediate question, please have a look at the JSSE API's,
>especially those that deal with getting SocketFactories from the
>initialized SSLContexts. You use the new socketfactories created by
>the SSLContext to create sockets, and you can set these socket
>factories in HttpsURLConnection.
>
>Brad
>
> >Sorry I'm a newbie and am also seeing the same unacceptable startup delay
> >(13 secs) - in a command line tool.
> >I realize I don't understand much about JCA. The only thing I want to
> >achieve is that a third party library (or even better, the entire JDK) uses
> >an algorithm that meets performance needs. /dev/random or even
> >java.util.Random would in many cases be preferable to secure but
> >unfortunately unusable algos.
> >
> >Now I can't see any difference by trying the suggestions below.
> >
> >For example, the line
> >
> >sr = new SecureRandom(new byte [] {25,13,32,5});
> >
> >does not make anything faster. Perhaps <sr> needs to passed to some method?
> >
> >com.sun.net.ssl.SSLContext.init(null, null, sr)
> >
> >can only be called if one already has a context in hand. Where and how do I
> >get a context?
> >
> >I tried
> >
> >com.sun.net.ssl.SSLContext.getInstance("SSL").init(null, null, new
> >java.security.SecureRandom(new byte [] {25,13,32,5}));
> >
> >to no effect. Perhaps I need to store the SSLContext somewhere. If so,
> where?
> >Obviously I am missing out on something here.
> >Help, anyone?
> >
> >(I see that in JDK1.4 the java.security file can be configured to use
> >/dev/random. But we are still 1 year away from using 1.4 in a production
> >environment)
> >
> >Wolfgang.
> >
> >> >Will be there a faster version of JSSE ?
> >> >I am using JSSE 1.0.1 and it is very slow (especially the handshake,
> >> >which lasts round 30 seconds).
> >> >
> >> >Thanks in advance for your answer.
> >>
> >>
> >>
> >>Hello Pierre and Jonathan (and other viewers of the java-security
> >>archives):
> >>
> >>Pierre and Jonathan have both noticed that JSSE/SSL connections can
> >>take a long time to negotiate initially.
> >>
> >>As Jonathan guessed, the reason is that the default SSLContext
> >>implementation needs to have a source of random numbers. As you may
> >>know, generating true randomness is a hard problem. There are some
> >>algorithms which do a good approximation, one of which was
> >>built into the JDK (SHA1PRNG).
> >>
> >>JSSE/SSL depends on psuedo-random numbers for its security, and
> >>therefore calls the constructor for java.security.SecureRandom(). It
> >>takes a significant amount of time to create a initial calculated value
> >>(seed), but once set, future calls to SecureRandom.nextInt() are much
> >>faster.
> >>
> >> Initial Subsequent
> >>On my Ultra 60: 14 seconds 1 second
> >>On my slow laptop PC (200 Mhz) pentium: 36 seconds 1 second
> >>
> >>If you were to preseed the generator, say:
> >> sr = new SecureRandom(new byte [] {25,13,32,5});
> >>things goes much faster:
> >>
> >> Initial
> >>Ultra 60: <1 second
> >>Pentium: <1 second
> >>
> >>I *HIGHLY* do not recommend hardcoding numbers into your apps, as you
> >>are losing all randomness (and therefore security). DON'T DO THIS.
> >>However, if you are able to come up with a good alternate source of
> >>random numbers, say a piece of hardware that generates numbers (e.g. "a
> >>radiation detector or a noisy diode" as the JDK SecureRandom API
> >>says)...
> >>
> >>
> >>There are a couple of workarounds:
> >>
> >>1) Precreate a SecureRandom object, call next*() to initialize
> >>the seed, and then pass the object to:
> >>
> >> com.sun.net.ssl.SSLContext.init(KeyManager, TrustManager,
> >> SecureRandom)
> >>
> >>Do this as part of your app. startup. Then, when you actually are
> >>ready to start your SSL negotiations, the seed has already been
> >>set, and the SSL negotiations go quickly. I'm guessing Netscape and
> >>others use part of their long startup time to do their random number
> >>generation, but I don't know for sure. Once the SSLContext has been
> >>initialized, things are much faster.
> >>
> >>
> >>2) Replace the default implementation of SecureRandom with your own
> >>implementation that's faster. In order to do so, you will need
> >>to implement a provider that comes before the standard Sun implementation,
> >>thus you will need to either add the provider by either adding it
> >>statically:
> >>
> >> update the <java-home>/lib/security/java.security file
> >>
> >>or dynamically:
> >>
> >> call java.security.Security.addProvider() or
> >> java.security.Security.insertProviderAt()
> >>
> >>See the SecureRandom/SecureRandomSPI pages for more information about
> >>how to write such a provider.
> >>
> >>We are looking for faster secureRandom generators, hopefully we'll
> >>be able to address this in a future release of the JDK.
> >>
> >>I hope this helps your understanding, and might give you some possible
> >>options. Good Luck,
> >>
> >>Brad
> >
