With lot of patience and hard work, I have got certain chapters of my upcoming book J2EE Security for Servlets, EJBs and Web Services ready for review. If the topic is of interest, please check it out and send me your valuable feedback.
Last Friday (March 28), I made this presentation on J2EE Security for Servlets, EJBs and Web Services, at SDWest2003, Santa Clara Convention center.
Though the overall participation was lower than last year, I counted more people in the audience for my session than the last year's Cocoon Presentation. May be it is a reflection of the fact that Security is a hot topic. Good news for my book!!
As an experiment, I uploaded few chapters of work-in-progress book J2EE Security for Servlets, EJBs and Web services for review by anyone who agreed to look at the chapters for review and personal use only and was willing to provide a contact email address. Besides announcing it at my weblog, I sent out a mail to an HP internal mailing list. My expectations were modest, but still I thought that I would get some good comments.
More than 50 people registered for review. The interesting thing was that only around five were HP internal. I was quite surprised that remaining came by reading my blog entry. But something was amiss. The number of folks who read the blog entry was much smaller. So who did the promotion?
This mystery got resolved by sheer chance. I was going through my website usage reports and there I noticed that the top search keywords for my site were "j2ee security". I entered j2ee security in my Google bar, and lo -- the third entry was my announcement page, out of a total resultset of 308,000 entries. I must have done something right in my message!!
This explained everything. Surfers were being directed to my chapters by none other than Google, Yahoo and perhaps others.
I sent out an email reminder to all those who had registered after six week of the original post. Four of the email addresses turned about to be non-operational (or with typos). This was quite encouraging (I expected half the folks to give bogus email addresses -- My registration s/w was a free s/w that did not validation but perhaps this was not known to downloaders).
My enthusiam turned out to be short-lived. Comments came from only one person. And this was a colleague !! No luck with random reviewers.
Okay. I learnt my lesson. No more upload for random reviews.
Luckily, the reviewers recruited by my publisher liked the manuscript snd have come up with some great feedback. The editor was excited reading those reviews and so was I. Let us hope the book comes out on schedule and does some business!
Among all the chapters for J2EE Security book, the one on Web Services Security was most difficult to write. More so because I wanted the intended audience for the book, and hence this chapter, to be developers.
Writing about SSL based transport security was straight-forward. In fact, I had done some work in this direction long ago.
Most of the literature I came across talked about yet-to-come security standards. Even these standards were for securing XML and SOAP messages. I am talking specifically of WS Security. Even now, after the book is out in the market, the Oasis TC developing this specification has not completed its work. The Java API standards or even proprietary implementations were even harder to find.
So I ended up doing some heavy lifting and doing my own implementation based on VeriSign TSIK library that provides a WS Security implementation based on the initial WS-Security specification. I basically wrote JAX-RPC compliant handlers which made use of TSIK library to apply WS-Security based protection on SOAP messages and tested these on Apache Axis.
During this implementation, I did run into an interesting problem. The TSIK library worked on a W3C DOM document or Node, but what you got in a JAX-RPC handler was a SAAJ SOAPMessage object. Converting this into a W3C Document esentially mean't serialing the memory object and reading it back into a W3C DOM document. Once the WS Security related processing is over, this needs to be converted back into SOAPMessage. This is prohibitively expensive. (Note: SAAJ 1.2 has fixed this problem by requiring SOAPMessage to extend from org.w3c.dom.Node).
The good news is that you can read the complete chapter online as it happens to be the free sample chapter. The code is also available with an Open Source License.
JavaRanch Book Review team has this nice review of J2EE Security for Servlets, EJBs and Web Services.
Here are excerpts:
"Security is like spinach - it's good for you but not too many people like it. Most security books bore me to tears with page after page of description accompanying three lines of code. This book is different."
"The explanations throughout the book are clear and easy to follow with plenty of code samples to demonstrate how to use the various APIs associated with security in Java programs. The best part of the book is the many code samples provided and the detailed descriptions accompanying these code samples."
Like many others, I was hit hard by comment spam in recent weeks. This was compounded by the fact that MovableType doesn't have convenient interface for listing and deleting spam comments.
My solution: Disable comments. As this is not directly supported by MovableType admin. interface, I had to edit mt-comments.cgi file. This may be too drastic but I can't think of any other easy way to handle this in the short term. I will upgrade one MovableType has good safeguards in place.
JavaRanch has published my two-part article (Part-I, Part-II) on setting up SSH tunnel for RMI based distributed applications.
While researching for this article, one of my most interesting finding was that SSH tunneling offers the most elegant solution for the secure traversal of corporate firewall problem I have ever come across. It is much more functional (supports callbacks, server could be behind its own firewall and so on ) than the one based on RMI over HTTP and incorporates authentication, confidentiality and message integrity.
Given that setting up SSH tunnel so straight-forward, and offeres so many advantages, it is amazing that not much has been written about it.
Here is the general scenario: You have written a webapp that connects to a database. However, for this it needs a database username and password. You know that it is not a good idea to read password values from a configuration file, as anyone with read access to this file will get complete access to the database.
So, what do you do? One of the guys I came across had a clever solution to this problem. He had a configuration tool that asked the user to enter the password, encrypted the password and then stored the encrypted value in the configuration file. At the startup time, the webapp will read this files, decrypt it and then use the real password to connect to the database.
When I asked him what encryption key did he use and how did the webapp get it, he replied that he has the key deep buried in the code, away from the reach of most users.
Anyone who knows even ABC of security will realize that it buys him no real security, for anyone with slightest amount of determination will retireve the key within minutes. But apparently, his customers felt safe in the knowledge that the password is not kept in clear. I guess, few bothered to ask the details of the encryption process.
There is a straight-forward solution to this problem: ask the admin. to supply a password at the time of webapp start (or the webapp container start) and then use this password as the encryption key. However, it does make the process of startup a bit inconvenient.
MS-Windows stores certificates and private keys in a registry-based certificate store which are accessed by applications such as IE, Outlook Express, MS-Outlook and so on. MS CryptoAPI lets any WIndows application to access these certificates.
Java programs, on the other hand, must maintain their own certificate store in different file -- one for trusted CAs and one for personal certificates.
Wouldn't it be nice if Java programs running on Windows could access the default certificate store and save the poor user from the trouble of maintaining multiple stores and allow him/her to work with much nicer Windows CertMgr Wizards than the crappy keytool.
Well, this is now possible, at least in theory, through Assembla JCE Provider, a JCE provider that exposes a number of MS CryptoAPI capabilities. The provider itself is a thin wrapper over the MS CryptoAPI.
I played with it a little bit. Comes with a good Windows based installer. However, I had to manually copy the jar file in J2SDK_HOME\jre\lib\ext and modify the java.security file. Nice to see that the provider jar class is signed by JCE Code Signing CA.
Once installed, using this from my very own JSTK was straight-forward.
But before you rush to download, install and use Assembla JCE provider let me warn you that
The SSL support in J2SE (through JSSE) has changed a lot from J2SE1.4 to J2SE1.5. So, when I got a chance this weekend, I ran my favourite ssltool (part of JSTK) to collect some performance numbers.
Now, I know the pitfalls of microbenchmarks -- but they do have some utility in some scenarios. And I consider this parituclar scenario simulated by ssltool to be one of those: a client program establishes connection with the server, sends a fixed no. of bytes and the server echoes back the same data. The client does send and receive in a loop for a fixed no. of times and reports the duration of the loop.
For the numbers given below, I executed both client and server programs on the same Athlon 900MHz machine running W2K. The buffer size was fixed at 8KB and the loopcount was 2048. Also, I measured the elapsed time for two different cipher suites: SSL_RSA_WITH_RC4_128_MD5 and SSL_RSA_WITH_3DES_EDE_CBC_SHA, as shown in the following table:
| J2SDK1.4.1_02 | J2SDK1.5.0b1 | |
|---|---|---|
| SSL_RSA_WITH_RC4_128_MD5 | 8.6 secs. | 6.5 secs. |
| SSL_RSA_WITH_3DES_EDE_CBC_SHA | 45 secs. | 64 secs. |
Whatever be the reason , I only hope that Sun addresses this before their final release, for the cipher suite SSL_RSA_WITH_3DES_EDE_CBC_SHA is stronger and more widely used
There are times when I want to establish a terminal session to a machine outside the corporate Intranet. Normally, this is not possible as the corporate firewall blocks outgoing connections to normal login ports such as telnet and ssh.
However, they do allow outgoing HTTP connections to port 80. One can take advantage of this to tunnel SSH connection over HTTP as explained in SSH Proxy Command -- connect.c.
I have uploaded the slideset of my presentation titled My Locker, Your Locker, Our Locker -- Managing Keys and Certificates at SDWest 2004.
Worth a look if you are a Java developer and deal with security issues.
dominicdasilva recently asked this question in his welog: which J2EE Security book should he buy -- my J2EE Security for ... or Enterprise Java Security: ...?
Obviously, I was interested in reading at comments and was pleasantly suprised to see the following post: "I actually have both of them. They are both very good, very well written, and very accurate. I think the Marco Pistoia book is less example driven and because it has multiple authors the quality and style tends to vary a bit. The Kumar book is full of code samples and the writing is very consistently good. I think your best bet is to drop into your local bookstore and examine them both to decide which one covers the topics you are interested in the most detail."
My own advise is more pragmatic: "if you are looking for coverage of Kerberos, IPSEC, SAML, Liberty, XACML then you are better of not buying my book." However, I should add: "you won't be disapponited if you are beginner/intermediate in Java Security and seek to learn about JCA, JCE, PKI, JSSE Java APIs and details of XML-DSig, XML-Enc, WS-Security and security issues in RMI, EJB, Web Apps, and Web Services."
Don't take me wrong -- I don't mean to say that the JCE API is complex or the logic of providers is difficult to get right. The JCE framework itself is quite simple, in fact same as the JCA. The algorithms implemented by a JCE provider could be complicated, but that is not the point. One could develop a JCE provider by just writing a wrapper over some existing library (like OpenSSL or MS CAPI on Windows).
What makes writing JCE providers is the requirement that it must be signed by a certificate issued by, directly or indirectly, a certification authority with distinguished name of CN=JCE Code Signing CA, OU=Java Software Code Signing, O=Sun Microsystems Inc, L=Palo Alto, ST=CA, C=US. This is checked by the JCE engine that come with J2SE -- it simply refuses to load JCE provider jars that are not signed by an appropriate code signing authority.
As per the JCE documentation, if you are writing a JCE provider then you should make a request to Sun for a code signing certificate. This in itself is not bad. But the caveat is that you must be a vendor to actually get the code signing certificate. This will actually get verified -- making the whole process quite beurocratic and beyond the reach of individual developers. For example, I am interested in trying out my little wrapper over MS-CAPI, but I am not a vendor, and so cannot test my little program!
This was just a little annoyance with J2SE1.4.x, for I had figured out that I could simply remove the jce.jar from jre\lib, and place the opensource Cryptix implementation of JCE engine. This worked fine for all my experimentation. However, with J2SE1.5, the Cryptix JCE jar doesn't work. As I don't see much activity with Cryptix (actually, most of the time the website is down!), not much hope that I will have an updated opensource JCE engine.
And this is happening exactly when it has become somewhat interesting to plug-in my JCE provider to speed-up SSL processing in J2SE1.5 by simple configuration change (JSSE of J2SE1.4 didn't support pluggable crypto providers; JSSE of J2SE1.5 does.). How does Sun expect programmers like me to try out this new exciting feature!
I don't know the rationale of requiring signed JCE providers, but even if we assume that this is needed for some arcane reasons, it is possible to promote experimentation by allowing download of a JCE engine that doesn't require signed JCE provider for testing purposes. This will continue to allow Sun to have the same control over people or organization who distribute their providers, for the users of the JCE provider would still need signed jars.
Ovidiu Predescu, an old friend and now a Google employee, has written an excellent writeup on using ssh-agent on Windows XP for single authentication for all ssh-based logins. I got to follow his instructions and setup my Windows machines to use this!
A recent San Jose Mercury News article talked about some of the technologies/products for client-side solution to authentication at multiple websites: Windows password manager, roboform, iKey and so on.
Ofcourse, ssh-agent and these web sign-on products address different target markets, but attempt to solve the same problem.
Recently, I came across a variant of this problem -- we have a Java based client program that interacts with a number of different and independent Web Services. These Web Services could assign different usernames and passwords to the client, requiring the client to use something like a password manager.
Came across Google's SafeSearch preference setting while searching for parental control tools and techniques. Works quite well! Here is an example: Search results for 'whitehouse' with 'moderate filtering' returned around 1,250,000 entries with whitehouse.com, a known porn site, being the second entry. The same search query with 'strict filtering' returned only around 600,000 entries, and whitehouse.com was not there.
This appears to be a reasonable first line of defence for my 7 year old daughter against accidental wandering off in the cyber-space. Of course, this is pretty lame for someone more knowledgeable:
So, in near future, I plan to investigate some of the parental control software available in the market for their effectiveness. Will publish my findings here.
Few weeks ago I got an email message from my colleague Craig Bryant asking about potential fix for an annoying pause during startup of his Java program that did some crypto during initialization. He also attached his code, pin-pointing the problem to the first invocation of the call Cipher.getInstance("DES/CBC/PKCS5Padding"), which took more than 5 seconds to execute on an HPUX box with JDK1.4.1. Agreed that 5 seconds delay at startup is not a big deal, but is still unacceptable in most development and production systems.
I compiled and executed the program on my old and rusty W2K desktop (a Pentium 350MHz box), and confirmed the delay. I also found that the delay was cut by almost half by just switching from J2SDK1.4.1 to J2SDK1.4.2. Not surprising given the impressive optimizations reported in J2SE 1.4.2. Running the program on a more modern machine (say, a 2.0GHz box) further reduced the delay to a more acceptable sub-second range. I attributed this to slow-but-necessary security intialization overhead and forgot about it.
Craig later reported that he profiled the code and found that most of the delay was due to signature verification. This made sense. Invocation of Cipher.getInstance("DES/CBC/PKCS5Padding")would require execution of classes in a JCE provider and the JCE engine requires the provider to be signed by a certificate issued JavaSoft. It appears silly, at least for a standalone Java program running on a trusted machine, to verify the JCE provider jar every time the program starts.
Lateron, after reading the recommendation to run the server JVM for better performance (which made sense anyway, as the original program was to run as a server program), I tried the same program with java -server, only to find that startup delay was worse than without -server option, with a factor of 3.5! (a 0.9 sec. delay became a 3.2 sec. delay). Again, an explanation is not hard to come by: -server option causes the JVM to compile all the code used in verifying the signed jar to native code, even if the verification takes place only once. And because of this, the performance gain of running native machine instructions do not offset the time spent in doing the byte code to native code translation.
Although the previous story is in the context of crypto operations, the general observation that signed jar files introduce human perceptible startup delays, applies to many more situations. This delay is proportional to the size of the signed jar and not the size of classes that get used from this jar file. For example, the following HelloWorld.java program:
//File: HelloWorld.java
import lib.HelloWorldLib;
public class HelloWorld {
public static void main(String[] args) throws Exception {
HelloWorldLib.helloWorld();
}
}
------------------------------------------------------
// File: lib\HelloWorldLib.java
package lib;
public class HelloWorldLib {
public static void helloWorld() throws Exception {
System.out.println("Hello, World!");
}
}
takes around 280 milli seconds to execute when class lib.HelloWorldLib is packaged within a jar file. However, the execution time jumps to 700 milli seconds when this jar file is signed. Adding this class to a large existing jar file such as rt.jar (which is a 25MB monster!) and signing the resulting jar makes the execution time to be more than 7 seconds. Note: All measurements reported in this paragraph were made on a AMD Athlon 900MHz box running W2K, J2SE 1.4.2 and server JVM. The measurements of first few executions were discarded to allow for OS and filesystem cache warmup.
This is something to keep mind if you plan to deliver signed jar files!
I picked up this SONY Network Camera from local Frys for $200 with the idea of creating a ZoneMinder based home security monitoring system. But was thoroughly disappointed with it after playing for a couple of hours.
This page contains an archive of all entries posted to Pankaj Kumar's Weblog in the Security category. They are listed from oldest to newest.
Programming is the previous category.
Software Development is the next category.
Many more can be found on the main index page or by looking through the archives.