8.5 Secure Sockets Layer (SSL)

Java Servlet Programming, 2nd Edition > 8. Security > 8.5 Secure Sockets Layer (SSL)

< BACK

CONTINUE >

The Secure Sockets Layer protocol, or SSL, sits between the application-level protocol (in this case HTTP) and the low-level transport protocol (for the Internet, almost exclusively TCP/IP). It handles the details of security management using public key cryptography to exchange symmetric keys that encrypt all client/server communication. SSL was introduced by Netscape with Netscape Navigator 1. It has since become the de facto standard for secure online communications and forms the basis of the Transport Layer Security (TLS) protocol currently under development by the Internet Engineering Task Force. For more information on TLS, see http://www.ietf.org/rfc/rfc2246.txt.

SSL Version 2.0, the version first to gain widespread acceptance, includes support for server certificates only. It provides authentication of the server, confidentiality, and integrity. Here's how it works:

A user connects to a secure site using the HTTPS (HTTP plus SSL) protocol. (You can detect sites using the HTTPS protocol because their URLs begin with https: instead of http:.)
The server signs its public key with its private key and sends it back to the browser.
The browser uses the server's public key to verify that the same person who signed the key actually owns it.
The browser checks to see whether a trusted certificate authority signed the key. If one didn't, the browser asks the user if the key can be trusted and proceeds as directed.
The client generates a symmetric (DES) key for the session, which is encrypted with the server's public key and sent back to the server. This new key is used to encrypt all subsequent transactions. The symmetric key is used because of the high computational cost of public key cryptosystems.

All this is completely transparent to servlets and servlet developers. You just need to obtain an appropriate server certificate, install it, and configure your server appropriately. Information transferred between servlets and clients is now encrypted. Voila, security!

8.5.1 SSL Client Authentication

Our security toolbox now includes strong encryption and strong server authentication, but only weak client authentication. Of course, using SSL 2.0 puts us in better shape because SSL-equipped servers can use the basic authentication methods discussed at the beginning of this chapter without concern for eavesdropping. We still don't have proof of client identity, however after all, anybody could have guessed or gotten hold of a client username and password.

SSL 3.0 fixes this problem by providing support for client certificates. These are the same type of certificates that servers use, but they are registered to clients instead. SSL 3.0 with client authentication works the same way as SSL 2.0, except that after the client has authenticated the server, the server requests the client's certificate. The client then sends its signed certificate, and the server performs the same authentication process the client did, comparing the client certificate to a library of existing certificates (or simply storing the certificate to identify the user on a return visit). As a security precaution, many browsers require the client user to enter a password before they will send the certificate.

Once a client has been authenticated, the server can allow access to protected resources such as servlets or files just as with HTTP authentication. The whole process occurs transparently, without inconveniencing the user. It also provides an extra level of authentication because the server knows the client with a John Smith certificate really is John Smith (and it can know which John Smith it is by reading his unique certificate). The disadvantages of client certificates are that users must obtain and install signed certificates, servers must maintain a database of all accepted public keys, and servers must support SSL 3.0 in the first place. As of this writing, most do.

8.5.2 Configuring SSL Security

A web application that requires SSL (HTTPS) security can indicate this fact to the server using its deployment descriptor. When SSL is required, the web.xml file should be modified so that the <security-constraint> tag contains a <user-data-constraint> tag indicating the security requirements. Example 8-12 demonstrates this.

Example 8-12. This Collection Requires a Secure Connection

    <!-- ...etc... -->     <security-constraint>         <web-resource-collection>             <web-resource-name>                 SecretProtection             </web-resource-name>             <url-pattern>                 /servlet/SalaryServer             </url-pattern>             <url-pattern>                 /servlet/secret             </url-pattern>             <http-method>                 GET             </http-method>             <http-method>                 POST             </http-method>         </web-resource-collection>         <auth-constraint>             <role-name>                 manager             </role-name>         </auth-constraint>         <user-data-constraint>             <transport-guarantee>                 CONFIDENTIAL        <!-- INTEGRAL or CONFIDENTIAL -->             </transport-guarantee>         </user-data-constraint>     </security-constraint>     <!-- ...etc... -->

The addition of the <user-data-constraint> indicates that not only does this resource collection require its users belong to the manager role, but also the users must connect using a connection that is CONFIDENTIAL.

The <transport-guarantee> tag has two legal values: INTEGRAL and CONFIDENTIAL. INTEGRAL requires the data must be guaranteed not to change in transit. CONFIDENTIAL requires the data must be guaranteed not to have been read by an unauthorized third party in transit. A CONFIDENTIAL guarantee implies INTEGRAL. It's left to the server to decide what encryption algorithms qualify as INTEGRAL and what qualify as CONFIDENTIAL. Most common SSL algorithms qualify as both, although a server might treat 56-bit DES encryption as sufficient for INTEGRAL (because to be decoded it must not have changed) but not sufficient for CONFIDENTIAL (because it can be so easily cracked).^[4] In practical terms on the Web today, there is very little difference between the two, and CONFIDENTIAL is the standard guarantee.

^[4] A client/server connection across a secure Virtual Private Network (VPN) could meet the CONFIDENTIAL constraint, even without SSL being used.

The <auth-constraint> and <user-data-constraint> tags can exist with or without the other. For example, a credit card processing page will require CONFIDENTIAL communication but can remain viewable by all users.

8.5.3 Configuring SSL Authentication

As SSL 3.0 gains in popularity, more sites may want to authenticate users using their client certificate. This provides an automatic and secure method to determine the identity of the client user. Depending on the trust level associated with the client certificate, this authentication mechanism may be considered secure enough to support legally binding contracts and even online voting.

As anyone reading the past web.xml comments should be able to predict, authentication based on client certificates can be specified with a change to the <login-config> tag:

<login-config>     <auth-method>         CLIENT-CERT <!-- client must be recognized using X.509 cert -->     </auth-method> </login-config>

This tells the server that all authentication for this web application will be done using client certificates, instead of the traditional basic or form-based alternatives. The client will never see a login page, although the browser will prompt for a password to unlock their certificate before it's sent to the server. If the browser does not have a client certificate, access is denied.

8.5.4 Retrieving SSL Authentication Information

As with basic and digest authentication, all of the SSL details are handled by the server, transparent to servlets. In other words, there is nothing special a servlet must do to run inside a secure server! It is sometimes possible, though, for a servlet to retrieve useful SSL authentication information. For example, a servlet can ask if the connection to the client is secure using the isSecure( ) method:

public boolean ServletRequest.isSecure()

This method returns true if the server deems the connection secure. What strength of encryption constitutes "secure" depends on the server implementation; see your server's documentation for details. Unfortunately, there is no standard way for a servlet to request the actual encryption algorithm used for the connection or even the bit size (40, 56, 128) of the symmetric key used for encrypting. A server does have the option to make this available as a request attribute, but as of yet there is no standardized attribute name. Such a feature is expected in Servlet API 2.3 using the request attribute names javax.servlet.request.cipher_suite and javax.servlet.request.key_size.

When the client has been authenticated using CLIENT-CERT, the client principal name can be retrieved using the getUserPrincipal( ) method introduced earlier. The principal name is taken from the Distinguished Name field of the certificate.

Finally, anytime a client certificate is sent to the server (which can occur during the normal SSL 3.0 handshake process, even when CLIENT-CERT is not specified), a servlet can retrieve the client's certificate as a request attribute:

java.security.cert.X509Certificate cert =   (java.security.cert.X509Certificate)   req.getAttribute("javax.servlet.request.X509Certificate");

For any server running on J2SE 1.2 (JDK 1.2) or supporting J2EE 1.2, the request attribute javax.servlet.request.X509Certificate will return a java.security.cert.X509Certificate object representing an X.509v3 certificate (see your server's documentation for configuration instructions). Servers running JDK 1.1 that don't wish to be J2EE 1.2 compliant are not required to support this attribute (because JDK 1.1 alone does not include the java.security.cert package). The servlet in Example 8-13 prints the client's certificate chain, if available.

Example 8-13. Examining Client Certificates

import java.io.*; import java.util.*; import java.security.cert.*; import javax.servlet.*; import javax.servlet.http.*; public class X509Snoop extends HttpServlet {   public void doGet(HttpServletRequest req, HttpServletResponse res)                                throws ServletException, IOException {     res.setContentType("text/plain");     PrintWriter out = res.getWriter();     X509Certificate[] certs = (X509Certificate[])       req.getAttribute("javax.servlet.request.X509Certificate");     if (certs != null) {       for (int i = 0; i < certs.length; i++) {         out.println("Client Certificate [" + i + "] = "                         + certs[i].toString());       }     }     else {       if ("https".equals(req.getScheme())) {         out.println("This was an HTTPS request, " +                     "but no client certificate is available");       }       else {         out.println("This was not an HTTPS request, " +                     "so no client certificate is available");       }     }   } }

The X509Certificate returned can be picked apart and checked for validity, issuer, serial number, signature, and so forth. Printing each certificate as a String yields output as shown in Example 8-14. The first certificate is the user's public key. The second is VeriSign's signature that vouches for the authenticity of the first signature.

Example 8-14. The X.509 Certificate Chain for Ramesh Mandava

Client Certificate [0] = [ [   Version: V3   Subject: EmailAddress=rmandava@talentportal.com, CN=Ramesh Babu Mandava,  OU=Digital ID Class 1 - Netscape, OU=Persona Not Validated,  OU="www.verisign.com/repository/RPA Incorp. by Ref.,LIAB.LTD(c)98", OU=VeriSign Trust Network, O="VeriSign, Inc."   Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4   Key:  com.sun.net.ssl.internal.ssl.JSA_RSAPublicKey@5b5870e3   Validity: [From: Tue Oct 10 17:00:00 PDT 2000,                To: Sun Dec 10 15:59:59 PST 2000]   Issuer: CN=VeriSign Class 1 CA Individual Subscriber-Persona Not Validated, OU="www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)98",  OU=VeriSign Trust Network, O="VeriSign, Inc."   SerialNumber: [    1ef11638 5ab8aaa1 bfa2b1b3 c0fb9cd9 ] Certificate Extensions: 4 [1]: ObjectId: 2.16.840.1.113730.1.1 Criticality=false NetscapeCertType [    SSL client ] [2]: ObjectId: 2.5.29.32 Criticality=false Extension unknown: DER encoded OCTET string = 0000: 04 3D 30 3B 30 39 06 0B   60 86 48 01 86 F8 45 01  .=0;09..`.H...E. 0010: 07 01 08 30 2A 30 28 06   08 2B 06 01 05 05 07 02  ...0*0(..+...... 0020: 01 16 1C 68 74 74 70 73   3A 2F 2F 77 77 77 2E 76  ...https://www.v 0030: 65 72 69 73 69 67 6E 2E   63 6F 6D 2F 72 70 61     erisign.com/rpa [3]: ObjectId: 2.5.29.31 Criticality=false Extension unknown: DER encoded OCTET string = 0000: 04 2C 30 2A 30 28 A0 26   A0 24 86 22 68 74 74 70  .,0*0(.&.$."http 0010: 3A 2F 2F 63 72 6C 2E 76   65 72 69 73 69 67 6E 2E  ://crl.verisign. 0020: 63 6F 6D 2F 63 6C 61 73   73 31 2E 63 72 6C        com/class1.crl [4]: ObjectId: 2.5.29.19 Criticality=false BasicConstraints:[ CA:false PathLen: undefined ] ]   Algorithm: [MD5withRSA]   Signature: 0000: 5E EC 5C F9 96 D5 3F F6   19 8B 66 0A 46 DE 02 FC  ^.\...?...f.F... 0010: 52 4E 32 70 5E DA 8B 92   43 F4 19 51 C3 A3 36 7D  RN2p^...C..Q..6. 0020: 02 4A 5B 35 B6 76 05 F8   FE C0 4F D7 9C B1 5B BA  .J[5.v....O...[. 0030: EE 38 A7 98 C5 57 A7 6B   86 B9 B2 A1 4F 25 5F FF  .8...W.k....O%_. 0040: 0B 19 54 86 D7 14 7A F7   97 A1 E8 E7 D3 89 75 B0  ..T...z.......u. 0050: 72 4F 4B 77 E4 56 5D B2   40 D2 7E 69 26 77 DD F1  rOKw.V].@..i&w.. 0060: E6 31 3D F2 EF 5A 11 22   78 23 47 C2 D6 ED DD 14  .1=..Z."x#G..... 0070: 2F E9 2E 46 73 D9 20 72   BF 9B 6C 04 12 0D 68 C7  /..Fs. r..l...h. ] Client Certificate [1] = [ [   Version: V3   Subject: CN=VeriSign Class 1 CA Individual Subscriber-Persona Not Validated, OU="www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)98", OU=VeriSign Trust Network, O="VeriSign, Inc."   Signature Algorithm: MD2withRSA, OID = 1.2.840.113549.1.1.2   Key:  com.sun.net.ssl.internal.ssl.JSA_RSAPublicKey@9ae870e3   Validity: [From: Mon May 11 17:00:00 PDT 1998,                To: Mon May 12 16:59:59 PDT 2008]   Issuer: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US   SerialNumber: [    d2762e8d 140c3d7d b2a8255d afee0d75 ] Certificate Extensions: 4 [1]: ObjectId: 2.16.840.1.113730.1.1 Criticality=false NetscapeCertType [    SSL CA    S/MIME CA ] [2]: ObjectId: 2.5.29.32 Criticality=false Extension unknown: DER encoded OCTET string = 0000: 04 40 30 3E 30 3C 06 0B   60 86 48 01 86 F8 45 01  .@0>0<..`.H...E. 0010: 07 01 01 30 2D 30 2B 06   08 2B 06 01 05 05 07 02  ...0-0+..+...... 0020: 01 16 1F 77 77 77 2E 76   65 72 69 73 69 67 6E 2E  ...www.verisign. 0030: 63 6F 6D 2F 72 65 70 6F   73 69 74 6F 72 79 2F 52  com/repository/R 0040: 50 41                                              PA [3]: ObjectId: 2.5.29.15 Criticality=false KeyUsage [   Key_CertSign   Crl_Sign ] [4]: ObjectId: 2.5.29.19 Criticality=false BasicConstraints:[ CA:true PathLen:0 ] ]   Algorithm: [MD2withRSA]   Signature: 0000: 88 B8 37 3B DD DA 94 37   00 AD AA 9F E1 81 01 71  ..7;...7.......q 0010: 1E 92 6A 6D 2F F6 F1 9D   D3 CA 64 38 DC 1B 98 0C  ..jm/.....d8.... 0020: 07 86 5B 85 15 6A 0F B9   49 85 A4 95 F1 17 7D 67  ..[..j..I......g 0030: B4 7F 2D 2C DD 9A 42 9E   C3 3E B4 8E AA E5 0B 06  ..-,..B..>...... 0040: DE F2 56 2A FA 33 C7 BE   19 D7 53 4C C3 BD C8 E3  ..V*.3....SL.... 0050: 17 B5 A4 49 42 63 EC C2   A6 17 0F 5D 58 1A 49 3C  ...IBc.....]X.I< 0060: 90 5C 55 A3 65 20 00 FD   18 20 E5 5F 82 A6 B1 A8  .\U.e ... ._.... 0070: 92 C5 58 6A C1 8D 03 3C   EB C3 CD 05 A2 90 AE 6E  ..Xj...<.......n ]

< BACK

CONTINUE >