...

While HotJava prevents applets from actively opening connections that violate the user-selected security policy, it allows an applet to accept connections from anywhere. At this point, an applet only has to use any one of a number of channels to communicate where it is, and have the remote end do the active open.

What if I start a Java applet then send it a faked TCP/IP packet from another host? Can I hotwire an outgoing connection that appears to be from the victim host?

TCP/IP connections are not really all that directed. It is only the startup phase that is trully directed - someone has to start a conversation.

Planned sequence of events :

Mallet: Send out Java applet to Alice Send Bob a connection request packet on port 22 Alice's Java applet is accepting connections. Send Alice a "request" packet claiming to come from port 22 Should now have an outgoing connection.

???? I'm not a TCP/IP hacker (much). I'll ask our guru tommorow after we are done with the NSA.

Phill

For the most part this scenario would work. The Java Applett that is doing secure or authenticated work clearly must employ some form of embedded authenticatation. A cute trick we are employing in one applet under development here at LGT is an embedded stream based bi-directional encryption engine. It provides a direct mechanism to encrypt the data stream within the TCP datagram rather than outside of it. Since the datagram itself is untouched the simple interface that Java employs is unfettered. However this proces adds some performance overhead but allows for a virtual private network to be constructed directly from the server to the applet context. This project/concept will be released sometime in January along with some underpinnings to plug into the FSTC EPayment Handler and its Architecture along with the applett itself... Yes we will share it with the CypherPunks... It's the best way I know to get a public testing/err bashing and beta cycle on a concept., We really are not trying to build a product in this effort, rather the intent is to prove that although the general "external transport" is/may be unsecured, that the internal or upper layers do not necessarily suffer from the same security leakage or process models, and that secure transactions can successfully be layered upon these "existing" underpinnings if they are adapted properly. This is especially true with both HiJacking and Spoofing attack modalities. But in our model with the upper layers events are synchronized and validated such that there is little chance for these attack modalities to succeed. Again for the world to hear - The Java concept is a Transport Harness, not the entire magilla. Clearly that is what is going on here... Without thewse upper layers it is no safer than normal netscape or any other browser transport. Sincereley, Regards, T. S. Glassey Chief Technologist Looking Glass Technologies todd@lgt.com (415) 324-4318 -----BEGIN PGP SIGNATURE----- Version: 2.6 iQB1AwUBMFu5E6gNRnWhagU5AQHI+gL+Mwpcd3lAWd8FF06qcG6rnLhIYveHW71a XC7xh1T0uu8qnYX31yMp17OG28jWpKUbWec1IM9/eXOi+gInA7rKICWczV8zo9Z0 0puxjRRN7yO4KfRb3cPpk+r0p6pDg01Y =bTYb -----END PGP SIGNATURE-----