SSL/TLS

 

SSL/TLS

Secure Sockets Layer is defined by NetscapeCommunications Corporation for securing HTTP connections. Because SSLis implemented in Netscape's browsers, it has become a de factostandard for secure HTTP connection. Today, virtually all browsers andHTTP servers support SSL. The current version of SSL is 3. Based on SSLversion 3, the Internet Engineering Task Force (IETF, http://www.ietf.org/)defined Transport Layer Security 1.0. TLS 1.0 is almost identical toSSL version 3, so in this book we use the expression SSL/TLS to referto both of them. These protocols use X.509 certificates forauthentication.

As we discussed earlier, SSL/TLS provides solutionsto three security requirements: confidentiality, integrity, andauthentication. Confidentiality is achieved by using a symmetriccryptosystem, such as these.

• Data Encryption Standard (DES), which has a 56-bit key.

• RC4, or Ron's Code, which was developed by thefamous cryptographer Ron Rivest. Its key length is variable but isnormally 40 to128 bits.

Integrity is guaranteed by using a messageauthentication code (MAC) based on a secure hash function, such asMessage Digest 5 (MD5) and Secure Hash Algorithm 1 (SHA-1).

Client authentication is optional in an SSL/TLSconnection, but server authentication is mandatory. In other words, theclient always knows the server's identity, but in many cases the serverdoes not know the client's.

14.3.1 Server Authentication

Figure 14.1depicts how SSL/TLS works for authentication. To use SSL, a Web servermust acquire a server's digital certificate from a certificationauthority (CA), a third-party organization that issues digitalcertificates. A digital certificate guarantees that the public keycontained in it belongs to its owner so that the receiver of adigitally signed message can verify the authenticity of the signature.The digital certificate format used in SSL/TLS is X.509, defined by theInternational Telecommunications Union-TelecommunicationStandardization Sector (ITU-T).

Figure 14.1. Authentication in SSL/TLS

When a client connects to a server using SSL/TLS,the client and server first look for the strongest common cryptographicalgorithm and agree on it. Then they exchange a symmetric key that isused in the encryption of the message body. The key exchange is done byusing public-key cryptography as follows.

1. The server sends its X.509 certificate containing the server's public key.

2. The client generates a 48-byte random number, a premaster secret, and encrypts the number using the server's public key. It then sends the encrypted premaster secret to the server.

3. The server decrypts the encrypted premaster secret using its private key.

4. The server and the client, sharing the samepremaster secret, which cannot be obtained by anybody else, generatesymmetric keys for message encryption from the premaster secret andstart communicating using the generated keys.

Because only the server that owns the proper privatekey can decrypt the encrypted premaster secret (and thus generate theproper symmetric keys), the client knows, by decrypting the firstencrypted message from the server, that it is in fact talking to thecorrect server.

14.3.2 Client Authentication

Client authentication is optional in SSL/TLS.Although it is often reasonable for a client to stay anonymous in acommunication between a browser and a Web server, in many B2Bsituations client authentication is critical. Two client authenticationmethods are popularly used with HTTP.

• HTTP basic authentication (RFC 2617) combined with SSL/TLS without client authentication

• SSL/TLS certificate-based client authentication

We discuss both of these in the following two subsections.

Combining HTTP Basic Authentication with SSL/TLS

HTTP basic authentication (RFC 2617) is part of theHTTP protocol specification and is based on userids and passwords.Because both are sent without encryption (they are Base64-encoded butare not encrypted), this is not a secure method of authentication. Soit must be combined with SSL/TLS, which provides confidentiality.

When basic authentication with SSL/TLS occurs, the following takes place (see Figure 14.2).

Figure 14.2. HTTP basic authentication

1. The client connects to the Web server using a URL梖or example, https://www.powerwarning.com/. Note that the protocol used is not http: but https:, which refers to HTTP over SSL/TLS.

2. When the SSL connection is established, the clientknows the server's identity with confidence because of the server'sX.509 certificate. However, the server does not know the client'sidentity, so it replies with a return code of 401, thereby requestingthat the client authenticate itself.

3. The client sends its Base64-encoded userid and password in the HTTP header.

Now, all the data is going through the SSL/TLSconnection, so it cannot be stolen during transmission. Also, nomalicious server can successfully disguise itself as the original Webserver in an attempt to steal the user's password.

Certificate-Based Client Authentication in SSL/TLS

Using SSL/TLS certificate-based clientauthentication requires that the client obtain an appropriate digitalcertificate before connecting to a server. To obtain a clientcertificate, a client must generate a public key/private key pair inits client software. The private key is kept secret in a keystore, andit is usually protected by a passphrase. Then the public key is sent toa CA, and a signed certificate is returned.

The advantage of using certificate-based clientauthentication over HTTP basic authentication with SSL/TLS is that withthe former, it is possible to separate the application and theauthentication. That is, the application does not need to maintain auserid/password database. It only needs to verify that the certificatepresented by the client is indeed signed by a trusted CA.

Consider the following situation. Suppose our power warning service presented in Chapter 1cannot attract enough customers by itself, so we decide to partner withnine other companies that provide similar services on the Internet. Asa group of service providers, we offer a package deal to our commoncustomers. A customer pays a fixed monthly fee to a designated billingcompany for accessing ten different services operated by the tenindependent companies.

In this case, HTTP basic authentication with SSL/TLS has some drawbacks.

• Each application must maintain its own copy of the userid/password database. This entails associated security risks.

• The billing company must notify each company ofthe addition and deletion of new customers and changes to customers'payment status. In addition, this communication must be secure.

• The customer must manage ten different passwords(if the same password is used, a dishonest employee of, for example,company A can use your password to access, for example, company B'sservice in your name).

By contrast, when certificate-based authentication is used, applications do not need to do user administration. Figure 14.3shows the user presenting its certificate to companies A, B, and C.Because this certificate is issued by the CA, the companies can trustthat the user is in fact a legitimate user. Thus they are freed fromthe burden of the complex and possibly human-intensive task ofregistering and charging customers.

Figure 14.3. Use of client certificates

14.3.3 Selecting a Public-Key Infrastructure

For a server or a client to be authenticated inSSL/TLS, it must have an X.509 certificate issued by some CA. Issuingcertificates involves a set of policies, procedures, and mechanisms forreceiving a certificate request, verifying the identity of a requester,signing a certificate, revoking a certificate, and so on. These arecollectively called the public-key infrastructure, or PKI. You must decide what PKI to use with SSL/TLS. PKI can be any of the following.

• Commercial CAs issue certificates for generalInternet use. For example, Verisign issues certificates for e-mail andsoftware signing and even provides free, 60-day trial Class 1certificates for individual users. Anyone who has access to an Internete-mail address can obtain a Verisign Class 1 certificate. When usingthis certificate, however, you must be sure that the level of securityit provides is sufficient to meet your needs. A Class 1 certificateguarantees that the e-mail address of the certificate owner is uniquebut does not guarantee anything about the true identity of thecertificate owner. Although this level of security might be enough forcasual e-mail exchange, it certainly is not for serious e-businessuses. Verisign offers other classes of certificates of higher securitylevels. Class 3 certificates are the ones used in ordinary SSL/TLS Webservers.

• Outsource PKI to outside vendors. Operating a CAproperly is not easy. It requires a highly secure hardware and softwareinstallation that is professionally maintained, as well as securitypolicies and auditing rules, among other requirements. Therefore, it isreasonable to outsource the CA operation.

• Although operatinga CA properly is not an easy task, it is relatively easy to set up yourown CA using one of the CA software packages. This might be a goodchoice for trial and educational purposes because you can learn variousissues in issuing and revoking certificates. Running a private CA alsois a possible choice if your organization is serious about setting upits own PKI that will be used across many different applications.

In any case, it is very important that you documentyour certification policy that dictates the condition of issuing andrevoking certificates.

14.3.4 Configuring a Server and a Client for SSL/TLS

Now, let us show you how SSL/TLS can be deployed ina Java-based B2B application. Because software supporting SSL/TLS isbecoming popular, most of what you need to do to secure your Webapplication using SSL/TLS is to configure your software correctlyaccording to your policy.

Configuring a Server

Because certificate-based server authentication ismandatory in SSL/TLS, the first thing you need to do in configuring aserver for SSL/TLS is to obtain a server certificate. We assume thatyou have already decided which PKI to use. To obtain a servercertificate, you follow these steps.

1. Generate a private key/public key pair in the server's key-management software.

2. Send the public key along with the identityinformation of the server owner (or operator) to the CA. You might berequired to send an official document verifying this identity.

3. Once the CA is satisfied with the requester'sidentity and the fact that the key was generated by the requester, itcreates a certificate that binds the requester's distinguished name(DN) to the public key by signing the certificate. The signedcertificate is sent back to the requester.

4. The server administrator installs the certificate in the server software.

Next, depending on the client authentication method, you need to do one of the following:

• Configure the server's basic authentication.

• Install the trusted CA's certificate that is used for verifying client certificates for certificate-based client authentication.

In the case of using HTTP basic authentication forclient authentication, the same authentication mechanism that is usedfor controlling access to Web pages can be used for authenticatingrequesters to B2B applications. In Apache Web Server, the most popularHTTP server and also an HTTP frontend of many popular applicationservers, an access control file named .htaccess contains a reference to an authentication database. In the Tomcat application server we introduced in Chapter 10, a file named conf/tomcat-users.xmlis used as the authentication database. An authentication database canbe a flat file if the number of users is small, but you need to use amore efficient database when the number of users is large or the samedatabase needs to be shared by multiple servers. Apache Web Serverprovides a few options with respect to the authentication database. Themodule mod_auth_dbm allows a large database by means of UNIX's standard database API. The module mod_auth_ldap,although available only in Apache Web Server version 2, can be used forcentralizing many authenticating databases into a single directory.

When you use SSL/TLS certificate-based clientauthentication, no authentication database is necessary. Instead, theserver needs to be configured so that only client certificates that areissued by a trusted CA are accepted. This is done by installing thecertificate of the trusted CA in the server's keystore.

Configuring a Client

To configure a client for SSL/TLS, first you need toinstall the certificate of the CA that issues the certificates of theservers to which you intend to connect.

When HTTP basic authentication is used for clientauthentication, no additional configuration is necessary, but theclient program has to explicitly embed a userid and password into anHTTP header.

When SSL/TLS certificate-based client authenticationis used, you need to create a public key/private key pair and, in thesame process for obtaining the server certificate, ask your CA to issuea certificate for the key and install the certificate into yourkeystore.

Preparing Keys for the Samples in This Chapter

As we have seen, using SSL/TLS requires processessuch as generating a key pair, requesting a certificate, and installinga certificate. Unfortunately, there is no standard tool for performingthese tasks. The way these tasks are performed is largely dependent onyour server software, client middleware, and the PKI you use. For thereader's convenience, we created a set of keys and certificates thatare used in the sample programs in this chapter. The tools we used are keytool, which comes with Java 2 SDK, and OpenSSL, a popular, open source cryptography package. Figure 14.4shows the relationships between these keys and certificates along withthe filenames where these keys and certificates are stored.

Figure 14.4. Keystores used in this chapter

For the selection of PKI, we take the third approach (operating a private CA) that we discussed in Section 14.3.3.XML & Java Test CA is the name (more precisely, the distinguishedname, or DN) of our CA that issues all the certificates used in oursamples. (This is a private CA that we created specifically forevaluating the sample programs in this book and should never be usedfor production.) All the keystores have the certificate of this CA as atrusted entry. We used OpenSSL for creating the CA key pair and itscertificate. The CA key is in the file chap14/ keystore/cakey.pem, while the CA certificate is in the file chap14/keystore/cacert.cer.

In Section 14.3.5,we show you a sample client program for making an SSL/TLS connectionwith HTTP basic authentication. In this connection, the server will beauthenticated via an X.509 certificate. For this purpose, the clientkeystore, chap14/keystore/sslclient.ks, must have the CA certificate as a trusted entry.^[3] On the server side, we created a server public key/private key pair (we gave it the key alias sslserver) in the server keystore, chap14/keystore/sslserver.ks.Then we had our CA issue a certificate for this key, and we stored theissued certificate back into the keystore. During these processes, weused OpenSSL for issuing certificates, while using keytool to manage both the client and the server keystores.

^[3] In Sun's implementation of JSSE, which we use in Section 14.3.5, the default keystore is located at $JAVA_HOME/jre/lib/security/cacerts.Instead of having a separate keystore for your application, you caninstall the CA certificate into this default keystore. By default, itcontains a set of root CA certificates that are commonly used for Webservers.

We also prepared keys for executing the sample programs for XML Digital Signature, which we cover in Section 14.4. We created keys for signature and verification, which are stored in the keystores chap14/keystore/signature.ks and chap14/keystore/verification.ks, respectively.

The accompanying CD-ROM contains all the keys readyfor use. We also included on the CD-ROM a detailed explanation of howyou can build these keys from scratch using OpenSSL and keytool.

14.3.5 SSL/TLS Programming in Java

Now let us look at how we can use SSL/TLS from our Java programs.

Java 2 Cryptography Architecture

First, let us briefly touch on the Java 2cryptography packages. Collectively, they provide application programswith a very flexible way to select and use cryptographic algorithms. Wereview three such packages.

• Java Cryptography Architecture (JCA) is a basisfor Java 2's cryptography functions. It defines the architecture ofseparating the API and specific implementations as well as the API forthe digital signature and digest function. JCA has no encryption API,so it is not subject to the export regulations of the United States.

• Java Cryptography Extension (JCE) is an optional package that provides encryption APIs.

• Java Secure Socket Extension (JSEE) is an optional package that implements SSL/TLS using JCA and JCE.

The latter two packages may be missing in a standarddistribution of Java 2. If so, you need to obtain these packages andinstall them into $JAVA_HOME/jre/lib/ext.

The use of cryptography technologies is sometimesrestricted by government policies. For example, the United States posescertain restrictions on exporting strong encryption technologies (forexample, symmetric cipher cryptosystems with a key length of 128 bitsor more). To minimize the impact of such policies on applicationprograms, Java 2 employs a provider architecture, which provides a common set of APIs with pluggable implementation modules, called crypto service providers.Usually, an application does not need to specify which crypto serviceprovider is to be used. Instead, available providers are registered ina configuration file, $JAVA_HOME/jre/lib/security/java.security, as shown next, and the Java cryptography library will select from these the most appropriate provider for a given request.^[4] In this example, a JCA provider called sun.security.provider.Sun, a JCE provider called com.sun.crypto.provider.SunJCE, and a JSSE provider called com.sun.net.ssl.internal.ssl.Provider are configured.

^[4] In Windows, the configuration file is %JAVA_HOME%/jre/lib/security/java.security.

   :
 security.provider.1=sun.security.provider.Sun
 security.provider.2=com.sun.crypto.provider.SunJCE
 security.provider.3=com.sun.net.ssl.internal.ssl.Provider
   :

You can also configure other providers. If you wantto use IBM's implementations, the configuration file will look likethis. The number after security.provider. represents the priority of the provider when the library selects one.

   :
 security.provider.1=sun.security.provider.Sun
 security.provider.2=com.ibm.crypto.provider.IBMJCE
 security.provider.3=com.ibm.jsse.JSSEProvider
   :

A provider can also be dynamically added at runtime by executing the java.security.Security.addProvider() method like this.

java.security.Security.addProvider(new com.ibm.jsse.JSSEProvider());

However, this technique should not be used unlessthere is a good reason to do so, because hardcoding a crypto serviceprovider will constrain the environments in which your application canbe executed.

Using Java Secure Socket Extension

JSSE provides a socket-equivalent API for SSL/TLS.Therefore, once an appropriate keystore is properly configured, usingJSSE is fairly straightforward. The following is a snippet of Java codefor calling JSSE.

import javax.net.ssl.*;
      :
    SSLSocketFactory factory
             =(SSLSocketFactory)SSLSocketFactory.getDefault();
    SSLSocket socket = (SSLSocket)factory.createSocket("demohost", 8443);

The class SSLSocket is a subclass of java.net.Socket, so a socket created this way can be used as if it is an ordinary socket.

If the protocol being used is HTTPS梩hat is, an HTTP protocol over SSL/TLS?it is simpler to specify https as the protocol in a URL. When creating a URLConnection object, instead of calling the following:

URLConnection uc = new URL("http://www.abc.com/").openConnection();

you can call this:

URLConnection uc = new URL("https://www.abc.com/").openConnection();

One catch is that this feature is not part of theJSSE specification. But most implementations, including Sun's referenceimplementation, support this feature. When you run a program using thisfeature, you need to set a special protocol handler to the systemproperty java.protocol.handler.pkgs. You can do this by adding the following option in a command line when executing the java command.

-Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol

You also need to specify what keystore you want touse in the command line. The option you need is as follows. Thekeystore password, changeit in our prefabricated keystores, should be changed to the password of your keystore.

-Djavax.net.ssl.trustStore=./chap14/keystore/sslclient.ks
-DtrustStorePassword=changeit

Listing 14.1shows a simple client program that sends an HTTP GET request to aserver using an SSL/TLS connection with HTTP basic authentication. Theuse of SSL/TLS is specified by using a URL starting with https:.For HTTP basic authentication, the supplied userid and the password areconcatenated using a colon (:) as a separator; then the concatenatedstring is Base-64 encoded and added as an HTTP header named Authorization.

Listing 14.1 Client using HTTP basic authentication with SSL/TLS, chap14/ SSLClientWithHTTPBasicAuth.java

package chap14;
import java.net.URL;
import java.net.URLConnection;
import java.io.BufferedReader;
import java.io.InputStreamReader;

public class SSLClientWithHTTPBasicAuth {
    public static void main(String[] args) throws Exception {
        String url = "https://demohost:8443/xmlbook2/chap14/index.html";
        if (args.length > 0) url = args[0];
        String userid = "tomcat";
        if (args.length > 1) userid = args[1];
        String passwd = "tomcat";
        if (args.length > 2) passwd = args[2];
        URLConnection uc = new URL(url).openConnection();
        sun.misc.BASE64Encoder base64enc = new sun.misc.BASE64Encoder();
        String auth =base64enc.encodeBuffer(
                       (userid+":"+passwd).getBytes("UTF-8")).trim();
        uc.setRequestProperty("Authorization","Basic "+auth);
        BufferedReader ins = new BufferedReader(
                                new InputStreamReader(uc.getInputStream()));
        String line;
        while ((line = ins.readLine()) != null) {
            System.out.println(line);
        }
        ins.close();
    }
}

To run this program, you must include the systemproperties that we mentioned earlier in the command line as follows.Note that the command line is broken into multiple lines forreadability, but they must be typed in a single line.

 R:/samples>java
-Djava.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol
             -Djavax.net.ssl.trustStore=./chap14/keystore/sslclient.ks
             -DtrustStorePassword=changeit
             chap14.SSLClientWithHTTPBasicAuth

14.3.6 Firewall Considerations

When SSL/TLS is used for B2B communication, youshould consider how your firewalls are configured, as your server isprobably located behind the firewall that restricts TCP connections ina certain way. A typical firewall configuration is depicted in Figure 14.5,where the SSL/TLS server is sitting in a network segment bracketed by apair of firewalls. This network segment, which is isolated from boththe Internet and the intranet, is called the Demilitarized Zone (DMZ).

Figure 14.5. SSL server located in the DMZ

One firewall of the DMZ is facing the Internet andaccepts certain connections from the Internet to a selected set ofservers in the DMZ. The other firewall, facing the intranet, usuallyblocks all the inbound connections. Both of the firewalls allowoutbound connections for popular Internet applications, such as HTTPfor Web browsing. This configuration implements the policy "SelectedDMZ hosts are accessible from the Internet, but no hosts in theintranet are accessible from the Internet, even if some host in the DMZis compromised." With this configuration, all the SSL/TLS connectionsmust terminate at the SSL/TLS server in the DMZ. If the server needs tocommunicate further with some host in the intranet, a separateconnection needs to be established.

There are two ways to connect the SSL/TLS server inthe DMZ with a host in the intranet. One is to allow inboundconnections from the SSL/TLS server to the intranet host by carefullyconfiguring the inner firewall so that it only allows connectionsbetween the specific pairs of hosts on a specific port. The other wayis to prohibit all the inbound connections and let the intranet hostmake an outbound connection every time the connection is required.

14.3.7 Summary of Using SSL/TLS

We have looked at how we can use SSL/TLS forsecuring our B2B communications. Most of the task involvesunderstanding the available options, selecting the ones that satisfyyour security policy, and configuring the software accordingly. Theprogramming part is very small.

Because SSL/TLS-enabled Web sites are very popular,many companies let their firewalls allow HTTPS (port 443) connections.Therefore, an application sitting inside a company's firewall can havea direct secure connection to another company's server using SSL/TLS.It is said that in the United States, more than 50% of network crimesare committed from inside a firewall. Given this fact, the end-to-endsecurity achieved by SSL/TLS has a large value.

 

来源：http://book.javanb.com/xml-and-java-developing-web-applications-2nd/0201770040_ch14lev1sec3.html