Now say that you surf to www.xyz.com and request a Java class or set of classes to run a spellchecker for your Java−based word processor. The request you send to www.xyz.com will be misaddressed by your
machine −− your machine will erroneously send the request to the hackers machine since thats the IP address your machine has associated with www.xyz.com. Now the hacker is able to send you back a Java class. If that
Java class is suddenly trusted because, after all, it allegedly came from a commercial site, it has access that you wouldnt necessarily approve: perhaps while its spellchecking your document, it is also searching your
hard disk to find the datafile of your financial planning software so that it can read that file and send its contents back over the network to the hackers machine.
Yes, weve made this sound easier than it is −− the hacker would have to have intimate knowledge of the xyz.com site to send you back the classes you requested, and those classes would have to have the expected
interface in order for any of their code to be executed. But such situations are not difficult to set up either; if the hackers stole the original class files from www.xyz.com −− which is usually extremely easy −− all they
need to do is set themselves up at the right place in the DNS chain.
In the strict Java security model we explored earlier, this sort of situation is possible, but it is not dangerous. Because the classes loaded from the network are never trusted at all, the class that was substituted by the
hackers is not able to damage anything on your machine. At worst, the substituted class does not behave as you expect and may in fact do something quite annoying −− like play loud music on your machine instead of
spellchecking your document. But the class is not able to do anything dangerous, simply because all classes from the network are untrusted.
In order to trust a class that is loaded from the network, then, we must have some way to verify that the class actually came from the site it said it came from. This authentication comes from a digital signature that comes
with the class data −− an electronic verification that the class did indeed come from www.xyz.com.
7.1.2 Data Authentication
The second problem introduced by the fact that our transmissions to www.xyz.com must pass through several hosts is the possibility of snooping. In this scenario, assume that site2 on the network is under control of a
hacker. When you send data to www.xyz.com, the data passes through the machine on site2, where the hacker can modify it; when data is sent back to you, it travels the same path, which means that the hacker on site2 can
again modify the data.
This lack of privacy in data transmission is one reason you might want data over the network to be encrypted −− certainly if the spellchecking software youre using from www.xyz.com is something you must pay for, you
dont want to send your unencrypted credit card number through the network so that site2 can read it. However, for authentication purposes, encrypting the data is not strictly necessary. All that is necessary is
some sort of assurance that the data that has passed through the network has not been modified in transit. This can be achieved by various cryptographic algorithms even though the data itself is not encrypted. The simpler
path is to use such a cryptographic algorithm known as a message digest algorithm or a digital fingerprint instead of encrypting the data.
Encryption Versus Data Authentication
When you send data through a public network, you can use a digital fingerprint of that data to ensure that the data was not modified while it was in transit over the network. This fingerprint is
sufficient to prevent a snooper from substituting new data e.g., a new Java class file for the original data in your transmission.
However, this authentication does not prevent a snooper from reading the data in your transmission; authenticated data is not encrypted data. If you are worried about someone stealing
your data, the security provided by data authentication is insufficient. Data authentication prevents writing of data but not reading of data.
This can be a very important difference in countries that place import or export controls on encryption. Those restrictions do not apply to digital signatures, so the Java code that implements
digital signatures is freely available. Hence, it is easier to deploy an application that requires digital signatures than one that requires encryption.
Without some cryptographic mechanism in place, the hacker at site2 has the option of modifying the classes that are sent from www.xyz.com. When the classes are read by the machine at site2, the hacker could modify
them in memory before they are sent back onto the network to be read by site1 and ultimately to be read by your machine. Hence, the classes that are sent need to have a digital fingerprint associated with them. As it
turns out, the digital fingerprint is required to sign the class as well.
7.1.3 Javas Role in Authentication
When Java was first released and touted as being secure, it surprised many people to discover that the types of attacks weve just discussed were still possible. As weve said, security means many things to many people,
but a reasonable argument could be made that the scenarios weve just outlined should not be possible in a secure environment.
The reasons Java did not solve these problems in its first release are varied, but they essentially boil down to one practical reason and one philosophical reason.
The practical reason is that all the solutions were about to explore depend to a high degree on technologies that are just beginning to become viable. As a practical matter, authentication relies on everyone having public
keys available −− and as well discuss in Chapter 10, thats not necessarily the case. Without a robust mechanism to share public keys, Java had two options:
Provide no security at all, and allow applets full use of the resources of the users computer. By now, we know all the possible problems with that route.
• Provide the very strict security that was implemented in 1.0−based versions of Java, with a view
toward ways of enhancing that model as technologies evolved. While not the best of all possible worlds, this compromise allowed Java to be adopted much sooner than it would otherwise have been.
•
On a philosophical level, however, theres another argument: Java shouldnt solve these problems because they are not confined to Java itself. Even if Java classes were always authenticated, that would not prevent the
types of attacks weve outlined here from affecting non−Java−related transmissions. If you surf to www.xyz.com and that site is subject to DNS spoofing, youll be served whatever pages the spoofer wants to
substitute. If you engage in a standard non−Java, forms−based transmission with www.xyz.com, a snooper along the way can steal and modify the data youre sending over the standard HTTP protocol.
In other words, the attacks weve just outlined are inherent in the design of a public network, and they affect all traffic equally −− email traffic, web traffic, FTP traffic, Java traffic, and so on. In a perfect world, solving
these problems at the Java level is inefficient, as it means that the same problem must still be solved for all the other traffic on the public network. Solving the problem at the network level, on the other hand, solves the
problem once and for all, so that every protocol and every type of traffic are protected.
There are a number of popular technologies that solve this problem in a more general case. If all the traffic between your site and www.xyz.com occurs over SSL using an HTTPS−based URL, then your browser and the
www.xyz.com web server will take care of the details of authentication of all web−based traffic, including the Java−related traffic. That solves the problem at the level of the web browser, but that still is not a complete
