The following is slanted to the paranoid, consume with Salt... the way Netscape has implemented Java security in the 4.04 (and later) browsers is to allow digitally signed applets to request (and obtain) permissions to take field trips out of the sandbox. The browser config then either just grants access to these signed apps, or if no access has already been given it pops a message to the user asking for the privs required. for the details on this try: http://developer.netscape.com/docs/manuals/signedobj/capabilities/index.html To answer the questions asked, in a round-about sort of way... In the context of an applet, when opening network connections the following apply to Netscape 4.x: 1. Unless digitally signed, an applet can only make connections back to the webserver it was downloaded from, regardless of an intervening proxy. With digital signatures, signed Jar etc. It's possible to get permissions from the Users, through the browsers config, or a pop-up, to do anything! 2. As for the SSL questions, first an applet downloaded from an SSL connection is considered to be signed by the cert on that site, meaning it's possible for the applet to request permissions to do anything (read, write, delete files, open arbitrary files, sockets, you name it). -- new network connections, won't by default transact over the existing pipe, however I'd have to check if you can access it if you choose to. 3. No built-in DNS restrictions exist. 4. don't know specifically about the SOCKS client stuff, but you get the picture. ..... What this means is that if you write a malicious applet, it requests perms to the user to do something useful, like spell check your Address Book , and whileit has the perms to do that useful thing. goes and mails every file on the drive to me. Or, maybe just the interesting Quicken files. Or maybe it uses your HTTPS proxy to connect back to my webserver, to upload the files. Or maybe I port scan your local subnet and upload the results to back to me. My advise, turn Java off, only turn it on , om machines with just a browser installed, no data (important or otherwise) that is on a subnet that can't reach anything useful inside the home network. I can't wait till your refrigerator has an IP address for service, and your cable modem allows me to access to it. Talk about spilled milk. > I'm trying to understand the whole issue about Java applets and > Firewalls and have a few questions. If you received this email, I found > your email address while doing searches on the subject. I haven't found > direct answers to my specific questions, so I'm trying to get some > confirmation on what I've been able to determine thus far. If you can > help, I'd sure appreciate it. I'm in a bind right now. > > * Is the SOCKS proxy client in Navigator or IE used by the JVM to > allow any Java applet to open a socket through a firewall .... or ... > does the applet itself have to establish itself as a SOCKS client? > > * Does the destination server need to have SOCKS support or is > just the client and proxy server sufficient? > > * If the Java applet is loaded from an SSL-secured web page are > all communications via Java socket calls also protected by this sleeve > ... or ... must the java applet itself establish itself as an SSL client > and use java security APIs. > > * If a java applet is retrieved through a proxy server, does the > browser consider it downloaded from the proxy or the actual server? Are > there any problems given the network security sandbox and issues such as > proxy servers or routers which perform network address translation? > > * Must the server which is serving up the applet have reverse DNS > capability over the internet to conform to the sandbox restrictions? I > recall some mention of this a while back. > > Any help will be greatly appreciated. Thanks. > > > --------------------------------------------- > John Kirkilis - Product Development > NetSolve, Inc. (512) 795-3056 > johnkat_private > > "Entropy - it isn't what it used to be." >
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 12:58:41 PDT