|< Day Day Up >|
13.4 Using SSL from within J2EE Programs
Using the SSL support built into a J2EE product is a very simple and effective approach but in some cases may have some limits because the communication between the client and the server can use only the capabilities
The Java Secure Socket Extension is a set of Java packages and APIs that enable the use of SSL from within Java programs.  JSSE provides a framework and an implementation for the SSL and TLS protocols and includes functionality for data encryption, server authentication, message integrity, and optional client authentication. Using JSSE, developers can enforce secure passage of data between a client and a server running any application protocol over TCP/IP, such as HTTP, TELNET, or FTP.
From a programmatic point of view, the main advantage of using JSSE is that a programmer does not have to bother with the details of the record and handshake protocols and with the encryption and decryption of the information exchanged. The underlying JSSE implementation will take care of those details at runtime. This way, the risk of creating subtle but dangerous security vulnerabilities is minimized. Moreover, JSSE
The JSSE design resembles that of the Java Cryptography Architecture and Java Cryptography Extension (see Section 11.1 on page 377). Like the JCA and the JCE, JSSE provides both an API framework and an implementation of that API and is designed so that any vendor's implementation can be installed and used without having to recompile the application. JSSE uses the same provider architecture defined in the JCA and the JCE (see Section 11.1.3 on page 382). This enables applications to be vendor neutral, implementation independent, and, whenever possible, algorithm independent.
The JSSE API consists of the package
and its subpackage
. This API supplements the
In Section 4.10.1 on page 145, we studied how servlets can become HTTPS
13.4.2 Trust Managers
is a software component responsible for deciding whether the credentials presented by a peer during an authentication process should be
The J2SE reference implementation comes with a default truststore file called cacerts , located in the lib/security subdirectory of the Java home directory. This file contains the digital certificates of common CAs, such as VeriSign and Thawte. The default password to access and modify this truststore is changeit . Users of a Java system can specify a different truststore by setting the system property javax.net.ssl.trustStore to the truststore file of their preference. This can be done programmatically, through a call to java.lang.System.setProperty() , or statically, using the -Djavax.net.ssl.trustStore option of the java command.
Often, it is useful to keep regular keystore files separated from truststore files. A regular keystore file contains private information, such as an entity's own certificates and corresponding private keys, whereas a truststore contains public information, such as that entity's trusted certificate entries, including CA certificates. Using two different files instead of a single keystore file provides for a cleaner separation between an entity's own certificate and key entries and other entities' certificates. This physical separation, which reflects the logical distinction of private- and public-key material, gives system administrators more flexibility in managing the security of the system. For example, a truststore file could be made write protected so that only system administrators are allowed to add entries to it. Conversely, a
|< Day Day Up >|