| 1: | When is an managed object destroyed? |
| A1: | There is no way to know for sure. The only thing you know as a developer is that the object is destroyed sometime after your application is done using it. |
| 2: | How many .NET languages can mix managed and unmanaged code? |
| A2: | Only Visual C++ .NET allows for mixing managed and unmanaged code. |
| 3: | What is the feature of the CLR that keeps memory clean? |
| A3: | The garbage collector. |
| Top |
In this chapter, you looked at how to use the
JSSE to create SSL and TLS clients and servers in Java. You should now
have a good understanding of the API and how to use it, as well as some
idea of what is actually taking place when the SSL/TLS protocol
handshake is taking place.
Over the course of this chapter, you learned
How the basics of the SSL protocol work
How to create a basic SSL client and server to secure communications
How to use client-side authentication with SSL
How to use an SSL session information
Finally, you can make use of HTTPS, configuring your own SSL contexts using the KeyManagerFactory and TrustManagerFactory classes, as well as using the HostnameVerifier interface if you need to.
This brings the book to an
end. At this point you should have a good grounding in many of the Java
APIs related to cryptography and secure communications, as well as some
ideas as to how to use them. Cryptography and security are constantly
evolving areas, however, so always remember the title of this book
started with the word "beginning," and good luck and best wishes with
the rest of your journey.
The JDK is a programming environment for compiling, debugging, and running Java applets, applications, and Java Beans. The JDK includes the JRE with the addition of the Java Programming language and additional development tools and tool APIs. Sun's JDK supports Linux, Solaris, and Microsoft Windows (2000, XP, and Vista). Additional operating system and special purpose JVMs, JDKs, and JREs are freely available at http://java-virtual-machine.net/other.html.
Table 10-1 lists versions of the JDK provided by Sun Microsystems®. Download the most recent version at http://java.sun.com; download older versions at http://java.sun.com/products/archive.
| Java Development Kits | Codename | Release |
|---|---|---|
| Java SE 6 with JDK 1.6.0 | Mustang | 2006 |
| Java 2 SE 5.0 with JDK 1.5.0 | Tiger | 2004 |
| Java 2 SE with SDK 1.4.0 | Merlin | 2002 |
| Java 2 SE with SDK 1.3 | Kestrel | 2000 |
| Java 2 with SDK 1.2 | Playground | 1998 |
J2SE version 1.3 has completed the Sun End of Life (EOL) process for the Solaris 9, Solaris 10, Windows, and Linux platforms.
In the previous chapter, we defined a customer test for adding and deleting a review from the database and then built the implementation accordingly. In this chapter, we enhance the AddReview Web service to prevent a reviewer from submitting multiple reviews for the same recording. When a reviewer attempts to do this, the Web service should not add the review to the database; it should return the id of the review that already exists in the database. Here is this requirement expressed as a customer test:
fit.ActionFixture | ||
|---|---|---|
start | CustomerTests.ReviewAdapter | � |
enter | FindByRecordingId | 100001 |
enter | SetRating | 4 |
enter | SetContent | Test Fit Content |
enter | SetReviewerName | Example Reviewer |
enter | AddReview | � |
check | ReviewAdded | False |
check | ExistingReviewId | 100002 |
To run this script, we need to add a method, named ExistingReviewId, to the ReviewAdapter. For now, let’s fake the implementation and have the method always return 0. Let’s run the script and see if we get the failures that we anticipate. Here is the output of the script:
fit.ActionFixture | ||
|---|---|---|
start | CustomerTests.ReviewAdapter | � |
enter | FindByRecordingId | 100001 |
enter | SetRating | 4 |
enter | SetContent | Test Fit Content |
enter | SetReviewerName | Example Reviewer |
enter | AddReview | � |
check | ReviewAdded | False expected |
| � | � | True actual |
check | ExistingReviewId | 100002 expected |
| � | � | 0 actual |
The script fails as anticipated because there is nothing in the implementation that prevents the user from adding a review to a recording as many times as he likes. In turn, we also run the programmer tests. Because all the programmer tests pass, there must be a missing programmer test. Let’s write a programmer test that exposes the problem and drives the implementation.
Because DTD conformance is important for Validator tags, a brief overview of how XML DTDs work is given here. DTDs specify a set of tags and attributes that make up a specific XML document type. DTDs also specify the order in which tags must be placed in the file, and the relationship between tags. For example, a tag definition defines what other tags can be nested inside of it, how many occurrences can be nested, and in what order the nesting can occur. Additionally, DTDs define which tag attributes are required and which are optional.
Each tag described in this chapter has a DTD Definition section that lists the tag's definition in the Struts configuration file DTD. The definitions will be similar to the one shown in the following snippet:
<!ELEMENT form-set (constant*, form+)>
This example defines a form-set tag and the tags that can be nested inside of it. According to the definition, the tag can have nested constant and form tags. The asterisk (*) and plus (+) characters following the nested tags' names indicate the number of times the nested tag can be nested. The * character indicates that the tag can be nested zero or more (unlimited) times. The + character indicates that the tag must be nested at least once and as many times as you'd like. A question mark (?) character indicates that the tag can be nested zero or one time. No trailing character means that the tag must be nested exactly once and no more. If no tags can be nested inside the defined tag, EMPTY is used to denote that, as shown next:
<!ELEMENT arg EMPTY>
There are currently five encoding methods recognized for encoding ASN.1 objects into streams of bytes:
q BER encoding includes the Basic Encoding Rules.
q DER encoding includes the Distinguished Encoding Rules.
q CER encoding includes the Canonical Encoding Rules.
q PER encoding includes the Packed Encoding Rules.
q XER encoding includes the XML Encoding Rules.
I mention all of them for completeness, as you can see
the number of methods indicates that people have had a few goes at
producing encoding methods to date and there is probably still more to
be written. Fortunately, the only two methods of interest are BER
encoding and DER encoding.
BER stands for Basic Encoding Rules. As you've
probably guessed from the example encodings you've seen so far, BER
encoding follows the tag-length-value (TLV) convention. A tag is used
to identify the type, a value defining the length of the content is
next, and then the actual value of the content follows.
BER encoding offers three methods for encoding an ASN.1 object:
q Primitive definite-length
q Constructed definite-length
q Constructed indefinite-length
Simple types employ the primitive definite-length, bit
and character string types will employ whatever method is most
expedient, and structured types employ one of the constructed methods.
If an object is tagged with the IMPLICIT style, the encoding used is the same as that used for the type of the object being tagged. If an object is tagged with the EXPLICIT style, one of the constructed methods will be used to encode the tagging.
How is it decided which method is most expedient?
Strictly speaking, the decision is made on the basis of whether you
know how long the encoding of the object will be when you start writing
it out. However, in some cases, standards do specify BER
indefinite-length, so in situations like that, you will end up with
objects that are indefinite-length encoded regardless of whether it
would have been possible to hold the object in memory. To fully
understand what this means, you need to take a look at the three
methods in more detail.
The definite-length methods all require that you
know the length of what you are trying to encode in advance. The
primitive definite-length method is appropriate for any nonstructured
type, or implicitly tagged versions of the same, and an encoding of
this type is created by first encoding the tag assigned to the object,
encoding the length, and then writing out the encoding of the body.
You'll look at how the bodies are encoded in more
detail later, but how the encoding of the length is done is worth
looking at here. If the length is less than or equal to 127, a single
octet is written out containing the actual length as a 7-bit number. If
the length is greater than 127, the first octet written out has bit 8
set and bits 7-1, represent the number of octets following that contain
the actual length. The length is then written out, one octet at a time,
high order octet first.
For example, a length of 127 will produce a length
encoding with 1 byte of the value 0�7f, a length of 128 will produce a
2-byte encoding with the values 0�81 and 0�80, and a length of 1,000
will produce a 3 byte encoding—0�82, 0�03, and 0�e8. This is the
simplest method of encoding and, as you will see, is required for DER
encodings.
Length octets in this case are generated the same
way as for the primitive definite-length method, but the initial byte
in the tag associated with any object encoded in this fashion will have
bit 6 set, indicating the encoding is of the constructed type.
As you would imagine, the regular structured types such as SEQUENCE and SET,
or implicitly tagged objects derived from them, are still encoded as
the concatenation of the BER encoding of the objects that make them up.
Likewise, explicitly tagged objects are encoded using the BER encoding
of the object that was tagged. Where this does become different is when
bit string and character string types, or implicit types derived from
them, are encoded using the constructed definite-length method.
When
this happens, the original bit string, or character string, is encoded
as a series of substrings that are of the same base type as the
constructed string. For example, if you are trying to encode a byte
array using the constructed definite-length method as an OCTET STRING, the encoding will start with an OCTET STRING
tag with bit 6 set indicating that it is constructed. Then, after the
length octets, the body of the encoding will be made up a series of
smaller OCTET STRING encodings using the primitive
definite-length method, the sum of which will be the byte array that
you were originally trying to encode.
You might use this method where you have several
values that make up a single ASN.1 type that exist separately prior to
creating an encoding of the ASN.1 type. For example, an e-mail address
may be defined as a single ASN.1 type but be assembled from parts
"name" + "@" + "domain" prior to encoding, which can be encoded as
substrings of a constructed string representing the full address.
Unlike the previous two methods, the constructed
indefinite-length method does not require you to know the length of the
encoding you are trying to construct in advance. With this method, the
encoding of the tag value follows the same procedure as for the
constructed definite-length method; however, the length is written out
as the single octet of the value 0�80, and instead of being able to use
the length of the encoding to determine when you reach the end of the
contents in the body of the encoding, there is an end-of-contents
marker—two octets of the value 0�00, which actually equate to tag 0,
length 0. Other than the requirement for and the presence of the
end-of-contents marker, encoding of objects is handled in much the same
way as for constructed definite-length.
This method of encoding is useful where the length
of the value is not known at the time the tag and length for the value
is encoded. This method is common when encodings are very large and
memory or efficiency constraints prevent the entire value being
buffered to determine its length before encoding it.
The Distinguished Encoding Rules, or DER, are so
called because they make identical data within identical ASN.1
definitions reduce to identical binary encodings. This is particularly
important in security applications where the binary data will be
digitally signed. There is also an interesting covert channel made
possible with BER encodings where equivalent, but different BER
encodings can be used to transmit extra information. For example, an
octet string representing encrypted data could be represented using a
constructed method where the length of the substrings making up the
encrypted data could be used to leak information about either the data
itself or the key used to encrypt it. As DER always reduces a value to
the same encoding no matter what, such a covert channel is not possible.
DER adds the following restrictions to BER encoding to make this possible:
q Only definite-length is allowed.
q Only SEQUENCE, SET, implicitly tagged objects derived from SEQUENCE and SET, and all tags of EXPLICIT type use constructed definite-length.
q The length of the encoding must be
encoded in the minimum number of bytes possible. For example, no
leading zeros that add length but do not change the value of the item
being encoded are included.
q Fields that are set to their default value are not included in the encoding.
q The objects contained in a SET are sorted.
DER
encoding is the most common form of encoding you will encounter, and it
is also the simplest to perform. The only area of complication is the
sorting of the objects contained in SET objects. A DER-encoded SET
is sorted by ordering the objects inside it according to their encoded
value in ascending order. Encodings are compared by padding them with
trailing zeros so they are all the same length, with the result that a
DER-encoded SET will be ordered on the tag value of each object. Be careful about relying on this, though. A BER-encoded SET is not necessarily sorted, so if you are trying to write code to handle both BER-and DER-encoded SET objects, it is a mistake to rely on the ordering taking place.
| |
Chapter 11
|
| |
