Apache Jakarta and Beyond: A Java Programmeramp;#039;s Introduction [Electronic resources] نسخه متنی

17.6. Encryption and Server Validation

Passwords ensure that a user is who he or she claims to be, and encryption makes it difficult for unscrupulous users to use others' passwords. However, there are still several points of potential insecurity. First, the client has no guarantees that the server with which it is communicating is really who it claims to be. Second, there is the possibility that the communication between the client and the server will be intercepted by a third party. Recall that with encrypted passwords no cleartext version of the password is stored. However, the password is still transmitted from the client to the server in cleartext, so an eavesdropper may be able to capture it and, from then on, mimic the rightful owner.

Although spoofing and eavesdropping appear to be two unrelated problems, the solution to both is something called SSL, or Secure Sockets Layer. This is a feature built into all common browsers and most servers, including Tomcat. SSL is the basis for the "https" protocol, which is seen on almost every commercial Web site.

SSL is far too complex a subject to cover in depth here. Fortunately, it is possible to use SSL without fully understanding it, just as it is possible to use regular sockets without understanding the details of TCP/IP (Transmission Control Protocol/Internet Protocol).

Briefly, SSL requires the server to have a

certificate, a digital key that contains information about that server. This certificate must be digitally signed by a

certificate authority. Such an authority is an established company or individual who is widely trusted and whose security credentials are built into every browser. There are a few such companies; the best known and most widely used is Verisign.

When a browser connects to a server using SSL, the first thing the server does is transmit its certificate to the client. The client then verifies the certificate against its built-in list of certificate authorities. Then the client and server establish a format for encryption, and the conversation proceeds.

Note that the handling of the certificate and the encryption of the dialog are two conceptually independent processes. In principle either could happen without the other, but SSL is designed in such a way as to require both.

For many many applications, however, encryption is sufficient, and the proof of identity is unimportant. For these cases it is possible for anyone to generate a

self-signed certificate, in which the user generates his own certificate, listing himself as the certificate authority. This is essentially useless for security; it is as if "John Smith" were to establish his identity by saying "John Smith never lies, so when I say I am John Smith, you can believe me!" However, this will allow the certificate validation portion of the SSL transaction to conclude so that the encryption phase can begin.

The Java Development Kit comes with a tool for managing all manner of digital keys, including certificates, and it has facilities for the generation of self-signed certificates. This tool is called keytool, and it may be found in the bin directory under JAVA_HOME.

A new self-signed certificate for use with Tomcat can be generated with the following command:

keytool -genkey -alias tomcat -keyalg RSA

The genkey option tells keytool to generate a new key, the alias option gives the new key the name tomcat, and keyalg specifies an encryption algorithm.

Keytool stores keys in

keystores, which are binary files protected by passwords. A user may have any number of keystores; the default one is located in the home directory and is called .keystore.

When keytool is started, the first thing it will do is ask for the password to the keystore. The default value that is assigned to all new keystores is "changeit," a gentle reminder to select a new, more secure password. For the moment, however, this good advice will be ignored.

The rest of the interaction with keytool looks like this:

Enter keystore password: changeit
What is your first and last name?
[Unknown]: localhost
What is the name of your organizational unit?
[Unknown]: examples
What is the name of your organization?
[Unknown]: AWL
What is the name of your City or Locality?
[Unknown]: New York
What is the name of your State or Province?
[Unknown]: New York
What is the two-letter country code for this unit?
[Unknown]: NY
Is CN=localhost, OU=examples, O=ExampleCo,
L=New York, ST=New York, C=NY correct?
[no]: yes
Enter key password for <tomcat>
(RETURN if same as keystore password):

The values marked as unknown indicate that no previous value has been provided. If this key were later to be edited, the values in brackets would be replaced by the values provided here. The "first and last name" field should be filled with the name of the server by which people will connect to Tomcat. "Localhost" is used here because for testing Tomcat and the Web browser will be running on the same machine. For a public site, this name should be whatever users will enter as the URL, such as "www.somesite.com."

Finally, keytool asks for a password for the new key, as distinct from the password for the keystore as a whole. In the current implementation of Tomcat these

must be the same, so no new password was provided.

Next, the new key can be viewed by running keytool -list. This will once again prompt for the keytool password and print all available keys, as follows:

Enter keystore password: changeit
Keystore type: jks
Keystore provider: SUN
Your keystore contains 1 entry
tomcat, Nov 29, 2003, keyEntry,
Certificate fingerprint
(MD5): 02:97:2B:04:D1:B0:9B:E7:2B:F3:80:72:1F:E0:95:99

Tomcat can be configured to use SSL by placing another entry in server.xml. To make it even easier, this entry is already present in a default Tomcat installation, although it is commented out. Turning on SSL is therefore as easy as removing the XML comment tags around the following:

<Connector port="8443"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" debug="0" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" />

Most of these parameters can be safely ignored in common usage.

Once Tomcat is restarted, a browser can be directed to https://localhost:8443/. Tomcat will send its self-signed certificate, but because the browser will not recognize the certificate authority, it will pop up an alert similar to the one in Figure 17.2.

The exact form of this dialog will depend on which browser is used, but the relevant information should be equivalent. It is worth noting that if there is a mismatch between the name given to keytool and the server name in the URL, then an addition dialog will be presented warning of this mismatch. In this case no such warning is given because the name "localhost" is being used in both places.

Once the certificate is accepted, the browser may display a key icon or some other indicator that the connection is secure. Beyond that the interaction will proceed as it did before. In particular, if a user tries to access the "example" Web application, she will still need to log in, although now she can do so secure in the knowledge that her password cannot be intercepted by a malicious snooper. It is also worth noting that both BASIC and form-based authentication will continue to work under SSL.