FrontPage Feature

The Java Secure Socket Extension (JSSE) is a set of packages that enable secure Internet communications. It implements a Java version of the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. It includes functionality for data encryption, server authentication, message integrity, and optional client authentication.

Although the JSSE guide provides detailed information on the JSSE API and its use in application programming, this article dives deeper into the different message exchanges involved when a programmatic Java client communicates with a server over the SSL. It will help developers understand the fundamental but often overlooked JSSE concepts of keystore, truststore, cipher suites, certificates, and the public key infrastructure and help them solve some of the common programmatic and configuration issues that arise when developing Java clients that communicate over SSL. It enhances the JSSE guide documentation by walking the reader through a debug output and explaining each message exchange between a client and the server in detail. Before starting, it's important to note that JSSE is fundamentally different from the Java Authentication and Authorization Service (JAAS).

Secure Socket Layer

The SSL Handshake Protocol was developed by Netscape Communications Corporation to provide security and privacy over the Internet. SSL ensures that the communications between two parties is secured and encrypted. It ensures that an intruder on the network can't see the data exchange between a sender and receiver or decipher it in any form. SSL does this by fragmenting the message into multiple manageable blocks, applying a Message Authentication Code (MAC), encrypting the message, and finally transmitting it to the intended party.

One of the common uses of SSL is in Internet commerce. While Internet browsers have used SSL for several years now, its operation remains transparent to most users because the browsers have the in-built capability of creating a SSL socket to the server and handling all the underlying complexities.

Cryptography

One important concept used in SSL is cryptography. Cryptography is essential for the secure exchange of information across intranets, extranets, and the Internet. From a business point of view, the security functions enabled by cryptography are authentication, which assures the recipient of a message that the originator is who he or she claims to be; confidentiality, which ensures that a message can be read only by the intended recipient; and integrity, which assures the recipient that a message hasn't been altered in transit.

From a technical point of view, cryptography is the science of protecting data by mathematically transforming it into an unreadable format. For a typical Web user, the browser does this. In other words, when a user types a secure Web site in the URL (www.mysecuredsite.com), the browser ensures that server is who the server says it is. The server's authenticity is verified via the digital certificate presented by the server.

Public Key Infrastructure

Although any detailed description of cryptography is beyond the scope of this article, since Public Key Infrastructure (PKI) is a commonly applied cryptography technique in most current SSL implementations, it may be a good idea to touch on PKI briefly.

PKI is based on two keys - a public key and a private key - that are mathematically related, and are used in public key encryption. In public key encryption, the public key can be passed publicly between the parties or published in a public repository, but the associated private key remains private to the owner of the certificate. Data encrypted with the public key can be decrypted only with the private key and conversely data encrypted with the private key can be decrypted only with the public key. However, since the public key is publicly available, it would be naïve to encrypt data using the private key.

In browser-to-server communication over SSL, when the browser connects to the server, the server sends its certificate to the client. The server certificate contains, among other things, the server's public key.

In figure 1, when the browser connects to a secure site, the browser requests the server's certificate, which includes the server's public key. When it gets the server's certificate, the browser performs the following steps:

• Validates the certificate based on its authenticity and expiry.
• Uses the certificate it gets to generate its own private/public key pair
• Uses the public key from the server certificate to encrypt the data to send to the server.

At the end of this handshake, the browser has three keys:

• The server's public key - used to encrypt messages sent to server
• Its public key - to send to the server
• Its own private key - to decrypt messages sent by the server that are encrypted by browser's public key.

When the handshake is over, both the browser and the server are ready to communicate with each other over a secure channel. However, all the above message exchange between the browser and the server remains transparent to the user of the site. The user only has to tie in the URL of the server he wants to communicate with. The browser handled all of the message exchange, key generation, and SSL handshake. However, when a programmatic client connects to the SSL server, the client's developer needs to do a few configuration steps before it can communicate with a server over SSL.

With this brief introduction, let's get down to the details of each step a programmatic Java client follows when connecting to a server.

Client Configuration

Although developing a secured socket connection isn't significantly different from conventional socket connection programming, understanding the underlying message exchange is valuable in troubleshooting any issues that may arise.

As described above, the asymmetric key cryptography PKI requires that both parties involved in data exchange send each other their public keys. So, for a programmatic client to communicate with a server, the private/public key pair has to be generated and made available to the client program at runtime. Like a browser, the programmatic client's private/public key pair is derived from the server's certificates. However, since the server certificate is sent only when the client connects to the server, the client needs to get the server certificate by other means before initiating a SSL connection.

There are a couple of ways a client can access the server certificate. A quick and easy way is to use the browser's ability to import server certificates and copy that to the file. In other words, if the server that has the certificate hosts any Web application that can be accessed by an Internet browser over a SSL connection, you may be able to import the certificate from, say, Internet Explorer. (For a detailed description of how to import the server certificate from the browser, you should refer to the browser-specific help.)

The other option generally followed in the industry is to manually distribute the public key (certificate) of the server to the programmatic clients. Generally, the server certificates are in *.PEM, *.DER, or *.CER formats and typically contain information such as issuer, valid dates, signature algorithm (MD5, RSA), subject, and the public key of the server.

Once the certificate has been obtained from the server, it's stored in a keystore on the client machine so it's accessible by the client at runtime. In a JRE model the keystores primarily comprises two files: a "keystore" and a "truststore." The keystore consists of an entity's identity and its private key. The keystore is used for various cryptographic purposes. The truststore contains the public key, in addition to the entity's identity. A truststore is the keystore used when making decisions about what to trust. If you get some data from an entity that you already trust, and if you can verify that the entity is the one it claims to be, then you can assume that the data really came from that entity. Combined together these files are generically referred to as keystores.

The files are stored/imported in the keystore via a tool provided by JRE. In JRE, this tool is called a keytool and is available with the JRE distribution. For example:

keytool -import -alias myAlias -file CertGenCA.pem -keypass mypasswd -keystore
 securekeystore -  storepass mypasswd

This command creates the file name securekeystore and imports the certificate from the file CertCAGen.pem with the alias myalias. It also checks the validity of the certificate and ensures that the certificate hasn't expired. (For additional help on keytool, see the keytool documentation at http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/keytool.html)

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...