Secure Socket Layer Communications

Secure Socket Layer (SSL) is a protocol that Netscape developed to ensure privacy of communications over the Internet. The protocol resides in the network communications layer, above TCP/IP, but below the application layer. As a result of this placement, application layer protocols, such as Hypertext Transfer Protocol (HTTP) and File Transfer Protocol (FTP), can benefit from the services SSL provides, and secure versions of these protocols (HTTPS and FTPS) are commonly used. In this section, you learn how HTTPS can be used in developing Workshop applications to provide encryption as well as client and server authentication.

How SSL Works

Figure 14.1 shows the sequence of the simplest SSL exchange between the client (Web browser) and the application server behind Workshop, WebLogic Server. In this example, user authentication is not performed.

Figure 14.1. A sequence diagram of one-way SSL without client authentication.

The client's initial request to use HTTPS is the start of what's known as the SSL handshake . Along with the request, the browser sends information to the server to indicate the versions of SSL and the compression and encryption algorithms the client supports.

In return, the server sends a certificate back to the browser. The certificate includes

• The identity of the organization behind the server

• The certificate's expiration date

• A public key, corresponding to the server's private key, the combination of which provides the means for the client and server to talk securely

• The identity of the organization that vouches for the server organization and that issued the certificate, also known as a certification authority (CA)

Most browsers are configured to recognize certificates issued by a number of well-known CAs. If the CA is not on the browser's list, the browser opens a dialog box asking the user to manually accept or decline installation of the certificate. This allows the user to determine whether the server can be trusted before he or she enters valuable personal or corporate data.

HOW BROWSERS RECOGNIZE CAS

The identities of CAs are determined through certificates (often self-signed). Certificates of some well-known CAs, such as Entrust, are added to the system during browser installation.

Assuming that the certificate is from a legitimate CA, the request is then processed and the response is sent to the browser over a secure link.

Authenticating the Client

The previous example demonstrates an instance of one-way SSL, in which only the server is authenticated. There are two key ways of authenticating the client when using SSL: basic authentication and two-way SSL.

Basic Authentication

Figure 14.2 shows the process of basic authentication. When the user requests a restricted Web resource, the server notifies the browser that client authentication is needed. The browser then opens a dialog box for the user to enter a username and password.

Figure 14.2. A sequence diagram of one-way SSL with client authentication.

It should be noted that when basic authentication is configured, the browser doesn't prompt for a username and password until access to a restricted resource is requested . In the meantime, any number of unrestricted resources can be accessed without logging in. This deferral is known as "lazy authentication."

The username and password information is then sent back to the server, where the security service checks it against the repository of known users. After it is verified that the user is valid (authenticated) and should have access to that particular resource (authorized), the Web container provides access to the requested resource. If the user is not authorized to access the resource (for example, a casino guest tries to access the newsletter subscription list), the browser generates an appropriate error message.

Basic authentication can also be used without SSL, but it's not recommended. Without SSL, the username and password are passed to the server with only 64-bit encryption rather than 128-bit encryption, which makes the data vulnerable to being stolen.

Two-Way SSL

In the two-way SSL process, shown in Figure 14.3, both the server and client exchange certificates. Note that in this case, client authentication occurs in the initial SSL handshake phase rather than lazy authentication.

Figure 14.3. A sequence diagram of two-way SSL.

There is a definite tradeoff in choosing between basic authentication and two-way SSL. As you'll see in "Installing Certificates in the Browser," later in this chapter, two-way SSL does require personalized configuration on each client machine; basic authentication requires none. However, manually entering usernames and passwords is always susceptible to interception if, for example, the day planner where you store that information is stolen or if software to record keystrokes has been installed on your computer without your knowledge. Client certificates offer a convenient way to eliminate the need to log in or remember any passwords.

SHOP TALK : IMPROVING APPLICATION SECURITY WITH SSL COUNTERMEASURES

It's time for my public service announcement: You can never be too careful when it comes to application security. Hackers have found a wide variety of ways to attack the security of your enterprise applications. Luckily, SSL is able to thwart a great deal of them. Here are a number of common scenarios and the countermeasures that SSL provides:

1. Identity Fraud

   Scenario : Hacker taps a communication line between two individuals and poses as one party by sending a copy of the real party's certificate containing the public key.

   Countermeasure : Second party asks for a message signed with a digital signature of the first party. The hacker can't comply because only the private key (stored separately from the certificate and not distributed) can be used to sign a message.

2. Content Corruption

   Scenario : Hacker has one individual's private key and alters the content of messages being passed between them.

   Countermeasure : A checksum of the message, known as a message authentication code (MAC), is generated before the message is sent and is attached (signed, of course) to the message. The recipient check computes the message's MAC and compares it to the attached value. If the numbers are different, the recipient knows that the content has been altered .

3. Replaying Messages

   Scenario : Hacker sends copies of previously sent communications to confuse individuals and their applications.

   Countermeasure : Sender includes a sequence number when computing the MAC. Recipient checks this information against a value that's stored and incremented with every received message. If the numbers are different, the recipient knows that the message has been re-sent.

4. Dictionary Attacks

   Scenario : Hacker knows a cleartext part of the encrypted message being sent. He or she tries to find the private key by using every possible key to encrypt this cleartext and looking for the resulting string in the original encrypted message. Hacker then has the private key for deciphering all future messages.

   Countermeasure : Strong encryption algorithms, with keys equal to or greater than 128 bits, make it harder for hackers to test every possible combination.

Configuring SSL

The process for securing Web resources for SSL is fairly straightforward, but does require working with some files and tools outside the WebLogic Workshop interface:

1. Acquire and install digital certificates.

2. Enable SSL in WebLogic Server.

3. Configure encrypted access to the Web resource.

4. Specify HTTPS communication parameters for the resource.

Acquiring and Installing Digital Certificates

WebLogic Server provides a number of ways to create certificates and affiliated files (server private key and CA certificate) for development and testing purposes:

• Using the BEA demonstration certificates

• Using Sun Microsystems keytool utility

• Using the BEA WebLogic Server CertGen utility

When you're ready to purchase production-level certificates from a trusted CA, online resources can help you make a decision on which vendor to use. For example, the following site compares CAs and the SSL certificates they produce:

http://www.sslreview.com/index.html

Using the BEA Demonstration Certificates

During the installation of WebLogic Platform 8.1, demonstration server digital certificates, along with the affiliated private keys and CA certificates, are installed. They are located in the weblogic81\server\lib subdirectory under the BEA_HOME directory that was specified during installation.

To configure SSL communications, these certificates and keys must be loaded into a repository known as a keystore . WebLogic Server is, by default, configured with two keystores located in the same subdirectory as the demonstration certificates. As a result, for development and testing purposes, no further keystore configuration is necessary.

Using Sun Microsystems Keytool Utility

If the single supplied demonstration certificate is not sufficient, you can use the keytool utility from a DOS prompt to generate any number of private keys and affiliated self-signed digital certificates for testing purposes. The tool actually has multiple roles. It can be used to move certificates into the appropriate keystore after they have been created. Also, keytool can generate a Certificate Signing Request (CSR) that provides all the data a real CA needs to generate a production-ready digital certificate for use with WebLogic Server. Finally, after the certificate is obtained from the CA, keytool can be used to replace the self-signed test certificate with the new one.

For complete details on the syntax of keytool , please visit Sun's KeytoolKey and Certificate Management Tool Web page at

http://java.sun.com/j2se/1.4.2/docs/tooldocs/ windows /keytool.html

Generating additional server certificates requires configuring additional keystores, which is beyond the scope of this chapter. To learn more about how to accomplish this through the BEA WebLogic Server Administration Console, consult the online product documentation at

http://edocs.bea.com/wls/docs81/secmanage/ssl.html#1186338

Using the BEA WebLogic Server CertGen Utility

The CertGen utility is an alternative to keytool that enables developers to specify a correct hostname in the digital certificate to test hostname verification.

To generate test CA-verified certificates with the CertGen utility, follow these steps:

1. Select a working directory in which you want the certificate to be generated.

2. Copy the BEA Demonstration Certificates from the BEA_HOME\weblogic81\server\lib subdirectory into the working directory.

3. Enter the following command from a DOS prompt set to the working directory:

    java utils.CertGen password certfile keyfile [export] [hostname] [genCA] 

The definitions of each command-line parameter are provided in Table 14.1.

Table 14.1. Command-line Parameters for the CertGen Utility

PARAMETER	REQUIRED?	DEFINITION
password	Yes	Password for the private key
certfile	Yes	Name of the generated digital certificate
keyfile	Yes	Name of the generated private key
export	No	Used to create certificates with export-ready encryption (128-bit); by default, the utility creates certificates suitable for domestic distribution (1024-bit encryption)
hostname	No	Used when testing hostname verification
genCA	No	Used when generating a certificate for a demonstration CA

If you use this utility to create additional server certificates, you should consult the online WebLogic Server documentation to learn how to configure keystores, as mentioned in the previous section on keytool . Although keytool could install the generated certificates directly to the keystores, the CertGen utility relies on a separate command-line utility called ImportPrivateKey to load the certificate into a keystore. Complete syntax and usage examples of this utility are provided at

http://edocs.bea.com/wls/docs81/admin_ref/utils.html#ImportPrivateKey

In this chapter, you'll use CertGen to create a client certificate needed to configure and test two-way SSL. Because the certificate is stored on the client machine, no additional keystore configuration is necessary.

Table 14.2 lists the parameter values needed for the CertGen utility to create a client certificate for one of the casino managers.

Table 14.2. Parameter Values for Generating the Casino Manager Client Certificate with the CertGen Utility

PARAMETER	VALUE
password	HouseAlwaysWins
certfile	CasinoMgrCert
keyfile	CasinoMgrKey

Enable SSL in WebLogic Server

Out of the box, WebLogic Server is configured for one-way SSL, using the demonstration server and CA certificates and keys. As a result, no further configuration is necessary during development and testing of one-way SSL security.

If additional certificates are needed during development, or, when in production, if you need complete directions on tweaking the WebLogic Server SSL settings to use these new certificates, consult the online product documentation at

http://edocs.bea.com/wls/docs81/secmanage/ssl.html#1187399

For two-way SSL, some additional configuration is necessary to have the server request client certificates during the SSL handshake process. The easiest way to perform the configuration is through the WebLogic Server Administration Console. The steps are as follows :

1. If WebLogic Server is not already running, start it by selecting Tools, WebLogic Server, Start WebLogic Server from the WebLogic menu.

2. Launch the Administration Console from Workshop by selecting Tools, WebLogic Server, WebLogic Console from the menu.

3. Enter the administration account username and password. The default settings are weblogic and weblogic .

4. After the console window opens, click the Servers folder in the left pane to expand the folder.

5. Select the name of the server for which two-way SSL configuration is needed. By default, the Workshop server is called cgServer.

6. In the right pane, select the Configuration tab on the top row and the Keystores & SSL tab on the second row. The Administration Console view at this point is shown in Figure 14.4.

   Figure 14.4. Using the WebLogic Administration Console to configure two-way SSL.

   

7. Under Advanced Options, click the Show link.

8. In the Server Attributes section of the displayed window, set the Two Way Client Cert Behavior attribute to the Client Certs Requested and Enforced option. Table 14.3 summarizes the list of available options and definitions.

9. Click Apply and close the Administration Console window.

10. To complete the reconfiguration, the server must be rebooted. From the Workshop environment, click Tools, WebLogic Server, Stop WebLogic Server from the menu.

11. After the server has shut down, restart it by selecting Tools, WebLogic Server, Start WebLogic Server from the menu.

Table 14.3. Options for the Two-Way Client Cert Behavior Attribute

ATTRIBUTE	DEFINITION
Client Certs Not Requested	For one-way SSL, this is the default value.
Client Certs Requested But Not Enforced	If a client certificate is not returned, it proceeds with one-way SSL; when a protected resource is subsequently encountered , the username and password must be provided through basic authentication.
Client Certs Requested and Enforced	If a client certificate is not returned or is not trusted, the SSL connection terminates.

Configuring Encrypted Access to Web Resources

To ensure that access to a Web resource, such as an HTML page, servlet, JSP, or Web service, is encrypted, you must first specify that the resource requires protection. This is accomplished by adding a <security-constraint> XML element to one of the Web application's deployment descriptor files, web.xml . In Workshop, this file is displayed under the WEB-INF folder in the Web application project in your application. Double-clicking this file displays its contents in the Source View for editing.

The <security-constraint> element is composed of one or more <web-resource-collection> elements, each of which defines a related group of HTTP calls that need to be protected. The elements of the <web-resource-collection> element are summarized in Table 14.4. The key element is <url-pattern> , which defines the scope of the protection. You can configure this parameter to protect everything from the entire project to an individual method call.

Table 14.4. Elements of the <web-resource-collection> Element

ELEMENT	REQUIRED?	DEFINITION
<web-resource-name>	Yes	Name of the collectionused simply as an identifier.
<description>	No	Free-form comments on this collection.
<url-pattern>	No (collection is ignored if not present)	One or more elements used to specify what range of URLs is linked to this constraint.
<http-method>	No	One or more elements to specify which types of HTTP methods (for example, GET, POST) are linked to this constraint; without this element, the constraint applies to all HTTP methods .

After the resource is defined as protected, you must further clarify that access to the resource must be encrypted. This is accomplished by adding a <user-data-constraint> subelement with the value of CONFIDENTIAL to the <transport-guarantee> element.

This chapter illustrates the security configuration of some Web services for casino guest relations. The sample web.xml file shown in Listing 14.1 encrypts communications to the entire Reservations Web service ( reserveHotel and reserveAirline ), but encrypts only one of the methods under the Newsletter Web service ( subscribe ).

OTHER VALUES FOR THE <TRANSPORT-GUARANTEE> ELEMENT

Another possible value for this element is INTEGRAL , which ensures that a message's content hasn't been altered during transmission. This is accomplished by computing a checksum of the message before sending it and comparing the message against this checksum on the receiving end. However, it's of limited use in the context of this chapter because messages sent with this SSL configuration are unencrypted and, more important, because the value of CONFIDENTIAL already includes this checksum functionality.

Listing 14.1. Sample web.xml File for Configuring Security on the Casino Guest Relations Web Services

 <web-app> . . .     <security-constraint>         <web-resource-collection>             <web-resource-name>Guest Relations</web-resource-name>             <url-pattern>Reservation.jws/*</url-pattern>             <url-pattern>Newsletter.jws/subscribe</url-pattern>       </web-resource-collection>         <user-data-constraint>             <transport-guarantee>CONFIDENTIAL</transport-guarantee>         </user-data-constraint>     </security-constraint> </web-app> 

Specifying HTTPS Parameters for the Resource

The final step in configuring SSL is to specify the HTTPS settings for the resource requiring encrypted access. To do this, you must add a few XML elements to another Web application deployment descriptor, wlw-config.xml . In Workshop, this file is displayed under the WEB-INF folder in the Web application project in your application. Double-clicking this file displays its contents in the Source View for editing.

Listing 14.2 shows an example of the wlw-config.xml file for the Casino application. Within the <wlw-config> element, you must first add the <https-port> element to define what port should be used for secure HTTP connections in this Web application. If most of the Web resources in this application use HTTPS, you can set a global <protocol> element at this level. To set the protocol at the individual resource level, you would add a <service> element, with a <class-name> subelement specifying the resource and a <protocol> subelement.

Listing 14.2. Sample wlw-config.xml File for Configuring Security on the Casino Guest Relations Web Services

 <wlw-config> . .     <https-port>9002</https-port>     <service>         <class-name>Chap14Web.Reservation</class-name>         <protocol>https</protocol>     </service>     <service>         <class-name>Chap14Web.Newsletter</class-name>         <protocol>https</protocol>     </service> </wlw-config> 

Installing Certificates in the Browser

To test two-way SSL, you have to install both client certificates and the test CA certificate in your browser's certificate store. Each browser and browser version does this slightly differently. In Microsoft Internet Explorer 5.0, you select Tools, Internet Options from the menu and then click the Certificates button in the Content tab of the Internet Options dialog box. The resulting Certificates dialog box, shown in Figure 14.5, enables you to install the client certificate in the Personal category and the test CA certificate in the Trusted Root Certification Authorities category.

Figure 14.5. Installing the test client and CA certificates in Microsoft Internet Explorer.

Trade-offs of Using SSL

As you have seen in the previous sections, establishing one-way and two-way SSL communications is fairly straightforward and powerful. However, this security mechanism does have its limitations. Data is secured only while it's in transit. After the data has reached its recipientclient or serverits confidentiality could be compromised if the data is stored there.

You can overcome this problem, however, by encrypting the data. To this end, Workshop offers message-level security for Web services by implementing the WS-Security standard authored by the Organization for the Advancement of Structured Information Standards (OASIS). The drawbacks to this security mechanism are that it's not currently as widely used as SSL and its proper configuration requires more detailed security knowledge.

To find out more about this security option, you can consult the "Security" chapter of the BEA WebLogic Workshop Help system, and visit the OASIS Web Services Security Technical Committee page at

http://www.oasis- open .org/ committees /tc_home.php?wg_abbrev=wss