Hacking your way to smoother SSL testing: Follow up #1

Yup, after a long "break" from blogging, I have restarted my "engines" to blog about this topic. Decided to write more on this before my memory starts failing...

Back in 2006, I applied the short-circuit codes to go around using HTTPS without having the proper certificates imported to the local truststore...was doing some POC for sending SMS requests via web services to an SMS gateway provider. But the SMS sender is just a standalone Java program. The hack worked nicely.

Returning to the future (present day, 2009). But security has its price...'real' SSL certificates (even testing, self-signed ones) have an expiry. When the testing team must shift the server dates earlier or later to "sync" with the mainframe data, this may cause the certificates to "prematurely expire". Sure, just regenerate the self-signed cert and whack it back into the truststore. The "good" way to do it. Or just use HTTP, code's still the same, just a parameter change. "Oh but this won't simulate closely to the production environment. If something goes wrong because you skipped something, will you be able to bear the brunt???", says the support manager...and if testing team finds out then there will be ICBMs flying around (aka email wars).

But I am just not a "normal, well-adjusted" coder. Always trying to find ways to circumvent stuff :)...

So, I tried to apply the hack (previous post) to see if it still works in WebSphere Application Server (WAS). The DummySSLSocketFactory class have to be refactored to use javax.net equivalents of the Sun-specific classes used by the Java tip article (http://www.javaworld.com/javatips/jw-javatip115.html). First I tried it on a standalone program with a few JDKs:

• Sun JDK 1.4.2_18 - Failed (Noted in previous post, but after 2 years passed, I still have verify this)
• IBM JDK 1.4.1 (comes with WSAD) - Passed
• Sun JDK 1.6.0_10 - Passed

OK, WAS 5.1 is running on IBM JDK 1.4, so chances of success is high. I fitted the code to set the security property to use DummySSLSocketFactory in a startup class in my webapp. Added a logging statement to ensure that this code has been executed during server startup. Then the code to call a HTTPS web service is triggered....FAILED!

Hmm, strange. I suspected that the security property set failed to take effect. I looked up the javadocs for javax.net.ssl.SSLSocketFactory. There's a method "getDefault()" to get the default SSL socket factory object. Went back to the standalone test program and called this method and print the class name out before setting the security property and after setting it.

The output looked like this:
Before: com.ibm.jsse2.SSLSocketFactoryImpl
After: com.ibm.jsse2.SSLSocketFactoryImpl

Ahhhh....so calling SSLSocketFactory.getDefault() will render the security property setting to none effect. The above output is similar when testing the webapp in WAS...no effect.

So, there must be something "magical" going on in this SSLSocketFactory class. Ok, let's look at the source code. But the code isn't there in the JDK (src.zip). I can't believe my eyes, why is it absent in the uber source code zip file??? It's also missing in Sun JDK 1.6.

Well, maybe Google can give me some answers. Some folks are also puzzled by this, and there's even a bug submission (yeah, Bug ID 4811569, take a look: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4811569). Is it fixed? Nah, it's not a bug, evaluation:

Not a bug. What's in javax.net is part of the Security Code (JSSE) therefore, the sources are not available through normal means for export control reasons.
However, it is possible to get access to it through the SCSL process.
See http://wwws.sun.com/software/java2/download.html

OK lo, I'll go look them up sometime later.

So, the hack is not all-encompassing, after all, it's just a hack. Maybe if there's a way to inject a certificate into a truststore without the hassle of running keytool or ikeyman...sometimes the keytool doesn't work (due to a vendor solution putting in extra jars into the WAS JRE's lib/ext folder and screwing up the tool, and there's no other JDK/JRE lying around...ya, just install a clean JDK and use it...sure, but it's production environment, and I can't just install anything I like, and there are more than a dozen machines running similar applications...things get unnecessarily complicated when you are not in total control), and the only means of communicating with the machines in a DMZ is using SSH via VPN, which somehow is not able to display GUIs (is there a way, or maybe not allowed by firewall?). So, learn the ikeyman command line version, or find out how to inject certs programmatically?

I chose the way of the code...stay tuned for the next follow-up post...

Yes, I re-iterate, I am not a "normal, well-adjusted" coder.