If you want to add Secure Sockets Layer (SSL) functionality to your Java 1.3 application, you must supply server- and client-side code. Part one of this series walked through the server-side requirements. Now, we’ll look at the client-side coding you need before launching your SSL Java application.
The client-side code
The first step in writing your client-side code is to import the necessary packages:
You need these packages for both client- and server-side code.
The following statement creates a Socket object for SSL on the client side. This object represents the local socket this time:
The next statement (Listing A) dynamically registers a Cryptographic Service Provider to implement engine classes for specific cryptographic algorithms. The algorithms used here are the same as on the server side.
What’s different on the client side
The client-side part of SSL initialization shown in Listing B is quite different from that on the server side. SSLSocketFactory is used instead of SSLServerSocketFactory. This is similar to SSLServerSocketFactory, and you can change it to use another implementation.
This factory requires the IP address and the port number of the server instead of the local values. This is because the local IP address can be captured directly, and the port number on the client side is usually generated randomly, as done in TCP.
We don’t call a listen or accept method on the client side after constructing supported Cipher Suites, as we do on the server side. The client requests a connection to the server by sending a message through the SSL socket. The value of “true” inside the constructor of PrintWriter means that the println() methods will flush the output buffer automatically. At this moment, the server and the client will perform an SSL handshake to make an SSL connection.
Finishing coding usually means completing a project, but Java security programming is an exception. We still have to configure Java permission so that Java runtime will be allowed to perform JSSE functionality.
Strictly speaking, it’s not essential to configure Java permission when you move the JSSE package files to the Java-Home directory. If you don’t want to configure Java permission, you can simply copy all JSSE package files to the Java-Home directory. But when you have many clients, copying the files to the Java-Home directory of each one can be time-consuming. So, in this case, it is recommended to configure Java permission before you run your SSL programs.
After moving the JSSE files to a directory under your project scope, you can configure Java permission in the .java.policy property file. You’ll usually find this file at %USERHOME% on a Windows system. You should insert the following statement inside .java.policy:
permission java.security.SecurityPermission “putProviderProperty.SunJSSE”;
You can add a link so your applet users can download the modified .java.policy file, and instruct them to copy this file to %USERHOME%.
Before you compile
Before you compile your code, you should make a batch file to help you include JSSE files for compilation. If you put them on the same directory with other Java codes, you can reference the command shown in Listing C to mention your classpath explicitly.
It is also convenient to make a batch file to run the program, because you should call JSSE files again, as shown below:
java -cp ./jcert.jar;./jnet.jar;./jsse.jar; chatServer
If you run your program as an applet, you can place your JSSE files on a directory that Web users can access. The HTML snippet in Listing D shows an example:
Since JSSE is an extension for JDK 1.2 and JDK 1.3, implementing SSL requires a bit more work than in JDK 1.4. JDK 1.4 introduces many new features (the integration of SSL is certainly one of the most significant), and it is expected to become more popular as organizations start to incorporate it into enterprise development efforts. For now, however, the techniques we’ve looked at here will allow you to develop JDK 1.3 applications with SSL to protect your communication.