Although this discussion is titled, Java Security, it focuses primarily on network security, or, stated another way, security for Web-based applications that include Java components..
Security is not a singular concept. Several of the different kinds of flaws and their associated safeguards include the following.
Confidentiality
A message sent from A to B is not read by C. The usual approach to providing confidentiality is encryption, normally at the transport level.
Authenticity
A message said to be from A is really from A. Authenticity is protection against spoofing. The usual approach to providing authenticity is through some form of certificate that includes a digital signature. A related issue is non-deniability -- when a message is received by B from A, A cannot deny having sent the message, such as when placing an order or returning a legal document
Validity
A message sent from A to B has not been replaced or modified by C (or innocuously through some sort of transmission error). The usual approach to providing validity is by sending some form of hash or digest of the message along with the message.
Benignity
A program (applet) loaded from the network through a WWW browser will not harm the user's system in certain stipulated ways. The usual way of insuring an applet is benign is through a SecurityManager run by the browser.
Access
A set of files and directories or a set of objects is made available to particular users and/or groups and not others, for particular types of operations, such as reading, writing, and/or changing access rights.
In the context of Web-based applications such as those discussed in other lessons, benignity is likely to be associated with a potentially harmful thick client, namely an Applet. Java security mechanisms (e.g., Java Security Manager) are largely responsible for this responsibility and will not be discussed further here.
Similarly, access control is likely to be handled either by layers and/or resources built into the application, such as login verification and role-based object method control, or by the container, itself, through mechanisms such as WebSphere container-managed authentication and role-based access control. Consequently, access will not be discussed further here.
The focus here will be on providing support for the other three topics listed above -- confidentiality, authentication, and validity -- primarily thorough the network's transport layer. thus, it will emphasize the Secure Socket Layer (SSL) protocol used to support the HTTPS protocol. It will briefly reference its successor -- the Transport Layer Security (TLS) protocol.
Certificates
A major component in the SSL and TLS protocols is an encrypted certificate issued by some well-known third party that identifies a particular server, client, or other process. This Certificate Authority (CA) must be well-known since to be effective, the client or server performing authentication must already (and independently) have that authority's own public key. Thus, if you look within the security settings of a Web browser, you will find a list of recognized CAs, such as VeriSign, Thawte, etc..
Obtaining Certificates. Certificates are digitally encoded packages of information that attempt to identify a particular person and his or her organization as well as to identify the authorizing organization, itself. Certificates include the following information:
An application for a certificate is associated with a particular person and includes information about that person's organization, country, etc.
When the certificate is generated by the CA, it includes this information as well the CA's own similar signature.
It also includes a new public key for the applicant, an expiration date, and Domain Names for both the CA and the applicant.
All of the preceding is wrapped into a bundle and encoded with the CA's private key; hence, these data can only be decoded in the future by someone who (already) has the CA's public key.
Such certificates are included as one of several components in the messages that are sent back and forth between server and client during authentication.
Validating Certificates. Certificates offered by one party (e.g., a server) to another (e.g., a client) are validated by checking them against a particular set of conditions or questions.
The certificate is decoded using the CA's public key.
It checks the expiration date against today's date.
If so, it then decodes the CA's encoded signature within the certificate and checks the data included against already held data for that CA.
The Domain Name of the requester is then checked against the actual Domain Name used in the communication.
If the process is that for a server evaluating a request from a client, it may also check the user information included within the server against a list of known and permitted users for that system, sometimes managed in a separate LDAP server.
If all of this checks out for a server's certificate, the client will conclude that the server is authenticated.
Secure Sockets (SSL)
The most widely used mechanism for insuring confidentiality between a Web client and server and for providing basic machine-to-machine authentication is the Secure Sockets Layer protocol. (Note: SSL is being superseded by the open source Transport Layer Protocol (TLS), based on SSL 3.0; however, since the two are very similar, TLS is often mapped into SSL, and SSL is still widely used, this discussion of basic concepts is useful for a basic understanding of security concepts in Web-based systems. At some point it may be updated to describe TLS, per se, in more detail.)
SSL was originally developed by Netscape to provide these forms of security at an infrastructure level, rather than requiring each application to provide them individually. A good introduction to the topic is Sun's Introduction to SSL tutorial. A companion discussion is Sun's Introduction to Public-Key Cryptography. A detailed discussion that includes protocol-level examples and relates HTTPS to SSL/TLS is Jeff Moser's The First Few Milliseconds of an HTTPS Connection.
It is important to keep in mind that SSL is a protocol -- that is, a set of rules that describe a set of interactions between two systems. As such, it operates on top of TCP/IP but below HTTP, FTP, IMAP, etc. Thus, these latter protocols, and the applications they support, can use (or not use) SSL transparently, once the secure connection is established.
SSL supports three primary security functions:
- authentication of the server process to the client
- authentication of the client process to the server (optional)
- encryption of messages sent between the two, once a "handshake" is completed
As might be inferred from the above, the SSL protocol is actually comprised of two sub-protocols: an SSL Handshake protocol and an SSL Record protocol.
SSL Handshake Protocol
The SSL Handshake protocol is used for authentication and to establish basic parameters for subsequent interaction. One of the most important of these is the symmetric key that will be used by the SSL Record protocol for message encryption. This is done since symmetric key encryption is significantly more efficient than asymmetric, public/private key methods. However, public/private keys are used by the SSL Handshake, itself.
The protocol uses some eight or nine steps:
The client initiates a request for an SSL connection by sending the server the version of SSL it is using, cipher settings, some randomly generated data, and other information needed for communication
The server responds with similar information as well as the server's certificate.
The client authenticates the server, using the server's certificate and the procedure described above.
If the server is requesting client authentication, the client returns its certificate. It also includes data derived from the handshake so far to create a premaster secret, encodes it with the server's public key (included in the server's certificate), and returns it, as well.
If the server is requesting client authentication, it uses the client's certificate to authenticate it. It then uses its own private key to decrypt the premaster secret. Both the client and the server then perform a series of steps to generate a master secret.
Both client and server then generate symmetrical session keys that will be used during the session.
The client sends a message to the server saying all future messages will be encrypted with the session key. It then sends a separate message that is encoded with the session key.
The server sends a similar pair of messages to the client.
The SSL Handshake is complete at this point.
SSL Record Protocol
The SSL Record protocol simply defines the format of records that include the encoded data in the body that will be sent back and forth, once the SSL Handshake is complete. As would be expected, these records include a plaintext "header" portion and an encrypted data or "payload" portion.
HTTPS for Struts Applications
For Web-based applications, conceptual issues, such as those discussed above, must be translated into specific mechanisms that enable security in a practical way. The most common form of security used in this context is HTTP over SSL or TLS, referred to as HTTPS.
HTTPS is usually is usually enabled by enabling it within a Web server or container. This is done though the server's configuration files, with the server listening by default for secure connections on either port 443 or 8443. Once enabled, any URL that includes one of the server's designated secure ports will result in a secure connection between client and server. This mechanism is satisfactory for absolute URLs, but if the application makes use of relative URLs, as many do, issues arise. This is particularly troublesome for Struts applications that make extensive use of symbolic forwarding references.
Using HTTPS and SSL for Struts has been made possible through an extension developed the Apache Software Foundation, called sslext. Unfortunately, there is very little documentation for sslext, but one useful, concise description of setup and use is the concluding section of chapter 18 of James Holmes's Struts: the Complete Reference.
The basic steps for installing, configuring, and using sslext include the following:
1. Download and unzip the sslext package.
2. Copy the sslext.jar file to the WEB-INF/lib directory.
3. Copy the sslext.tld file to the WEB-INF directory.
4. Add a taglib reference to the web.xml file; when adding individual jsp pages, include a corresponding reference to this taglib:
<taglib> <taglib-uri>/tags/sslext.tld</taglib-uri> <taglib-location>/WEB-INF/sslext.tld</taglib-location> </taglib>5. Add type parameter to action-mapping tag in struts-config.xml file:
<action-mappings type="org.apache.struts.config.SecureActionConfig" >6. Add controller tag to struts-config.xml file:
<controller processorClass="org.apache.struts.action.SecureRequestProcessor" />7. Include plugin tag in struts-config.xml tag:
8. Include sslext taglib reference and sslext tags in jsp pages, as needed:<plug-in className="org.apache.struts.action.SecurePlugIn"> <set-property property="httpPort" value="8888" /> <set-property property="httpsPort" value="8443" /> <set-property property="enable" value="true" /> <set-property property="addSession" value="true" /> </plug-in>9. Include sslext set-property tags (true or false) within action tags in struts-config.xml file, as needed:<%@ taglib uri="/tags/sslext.tld" prefix="sslext" %><sslext:link action="/actionNavigate.do?userAction=loadLogin">Login Existing Customer</sslext:link><set-property property="secure" value="true" /> or <set-property property="secure" value="false" />