LDAP SSLConnection taking far too long

[Jamie Robertson]

I am using LDAP classes for Novell (V3). The SSLConnection class takes 35 seconds to create a SSL connection. This seems like it is WAY to long, but don't know where to start looking for performance gains. If it helps, this is the connection code(pretty much cut and pasted from the Novell sample code):

System.getProperties();
 
// Dynamically set JSSE as a security provider
Security.addProvider( new com.sun.net.ssl.internal.ssl.Provider() );
// Dynamically set the property that JSSE uses to identify
// the keystore that holds trusted root certificates
System.setProperty("javax.net.ssl.trustStore", KEYSTORE_PATH);
LDAPSocketFactory ssf = new LDAPJSSESecureSocketFactory();
  
//create a new connection
ldap_connection = new LDAPConnection( ssf );
 
// connect to the server
ldap_connection.connect( this.hostIP, this.port );
 
System.out.println( "Successful SSL connection with server.");

[William Brogden]

I seem to recall hearing about excessive delays caused by starting up a random number generator. Does the 2nd connection take as long as the first?
Bill

[Jamie Robertson]

Originally posted by William Brogden:
I seem to recall hearing about excessive delays caused by starting up a random number generator. Does the 2nd connection take as long as the first?
Bill

After more digging, you were right. If I run the application using the -Djavax.net.debug=all option, I can see that 34 or the 35 seconds were taken up by creating the secure random number. The only suggestion I've seen is to create the secure random number in a separate thread initially, then use it when I need it. Unfortunately, it's the first thing I need in my application, so that is not an option. I am using jdk 1.3.1, Windows 98 and jsse 1.0.3(I think). Would I see any noticeable performance gains by upgrading to JDK 1.4? How can I speed up this secure random number generation?
Jamie

[Brian Buege]

Check out these two links for alternative SecureRandom providers that use the native OS to generate the seed for SecureRandom.
http://www.isnetworks.com/infinitemonkey/
http://www.itworld.com/nl/java_sec/09072001/
The reason the default implementation of SecureRandom takes so long is that the provider spawns a ton of threads and then gauges their timing performing a set of operations to simulate a source of randomness. This is platform independent (doesn't rely on the native OS), but unfortunately not very performance friendly.
Additionally, when using SSL to connect to a LDAP provider, many people choose to go with a LDAP connection pool approach (for shared components) to further mitigate the time required for the SSL handshake. Based on your post though, it sounds like you may have a standalone client, so this may not help you too much.
Hope this helps!

[Jamie Robertson]

I'll have a look at your native code suggestions. This is the first procedure in a stand alone app, so pooling or creating it in a background thread for later won't work .
Thanks,
Jamie

[Brian Buege]

Another suggestion (that would compromise your app security slightly, but not as much as not using SSL at all) would be to write your own SecureRandom provider that wraps the normal Random class in Java. This would give you good speed, but reduce the strength of your encryption somewhat (if an attacker can guess your seed, then they can *potentially* break the encryption).
I'm not sure about what your exact security requirements are, but if it's OK to allow a stong crypto assault to possibly breach your app (there aren't many of these that happen -- at all), then this solution will work just fine. To all but a seasoned cryptanalyst (who also is able to guess your seed), your use of SSL will be completely secure.
I guess it's all about balancing risk of loss vs. cost of countermeasures. (My opinion) In your case, you might decrease the security of your connection by a fraction of a percent, but if a compromise of a user password would not compromise national security or cause imminent failure of the business, it's probably an acceptable risk.