Many users sit behind a corporate firewall or proxy server and use Netscape Navigator as their primary Web browser. These users cannot make use of Java applets that connect back to the applet's originating server because of Java applet security restrictions. For example, the applet-based site java.sun.com:81 and various applets that reside on the www.gamelan.com site, or are linked to from it, are not accessible to users behind a firewall. The typical error that comes up is: "# Security Exception: socket.connect:www.machine_name.com->www.machine_name.com."
To get around this security restriction, all you need to do is edit your local Domain Name Service (DNS) resolver configuration. For most Unix and Windows systems, this is often done by editing your local HOSTS file:
- Under Unix-like systems, this HOSTS file is "/etc/hosts"
- Under Windows 3.x and 95 systems, this file is "c:\windows\hosts"
- Under Windows NT systems, this file is "c:\Winnt_version\system32\drivers\etc\hosts," where Winnt_version is specific to the NT version.
Simply map the "machine_name" where the applet came from to some arbitrary Internet address. That is, add a line like the following to your HOSTS file: "www.machine_name.com 184.108.40.206." Then restart your Navigator browser, and you'll find that now you can use applets from www.machine_name.com.
A real example
As stated above, with Navigator, when a firewall/proxy server is present and the internal network does not provide external DNS resolution users cannot access the Java applet-based site at java.sun.com:81. The typical circumstance involves a user not having the capability to do external DNS resolution. Most (if not all) companies do NOT provide external DNS resolution. Simply by adding the line "220.127.116.11 java.sun.com" to their HOSTS file, users can now fully access java.sun.com:81.
How it all works
I believe the reason adding a line to the HOSTS file gives users access to the site is because of a small security glitch in how the applet security manager checks to see what IP address the applet came from. In the example above, the site of origin is java.sun.com, which maps to an IP address of 18.104.22.168 on my machine. Then when the applet wants to connect back to java.sun.com for whatever reason, the applet security manager again checks to see what IP address the applet wants to connect back to. Once again, java.sun.com will map to 22.214.171.124. The applet security manager then compares the identical 126.96.36.199 responses and allows the connection to be made.
Note: This security glitch requires some explanation and some understanding of Java applet security. If you look at what's on http://home.att.net/~wisniewski/DNSSpoofing.html, you will find an overview of the issues involved as well as links to the original sites that described DNS Spoofing concerns.
The security glitch occurs at the point that this second applet request is made: What is supposed to happen based on any secondary applet request is that the URL request should be rewritten from http://java.sun.com/whatever to http://188.8.131.52/whatever before the request gets passed from the applet to the browser and then to the firewall/proxy server. But the URL request does not get rewritten. The applet requests keeps the URL request as http://java.sun.com, which forces the proxy to do another DNS resolution.
There is one caveat -- a small, potential security risk of using this bypass mechanism. If your site's DNS resolution is not cached by your firewall/proxy server but rather is checked externally for every single request, the DNS resolution can be spoofed by the site that you downloaded the applet from. The resulting security hole is documented by Netscape at its Website (see the Resources section for the complete URL). Although the security hole was fixed by Netscape, I believe a small, less vulnerable hole still exists.
Learn more about this topic
- Netscape has documented the security hole at http://home.netscape.com/newsref/std/java_security_faq.html