JDK1.1 - Security on sockets

I would like to secure my sockets(IO) within an applet.

I am currently looking at the java.security api but am

not able to find a way of securing the sockets.

As the sockets are within the applet I would like to recieve a public key and start decrypting the input stream based on the public key. in this method correct?

Has anyone knowledge in this area with this version of the JDK.

Or does anyone know where I can purchase a security

api for this version that is fairly straight forward.

I am resricted by the version of JDK and using something like web start is not an option.

[635 byte] By [kitto] at [2007-9-26 3:14:57]
# 1
Hello Kitto,Unfortunatly you are on the wrong forum since JSSE requires at least JDK1.2.Francois
francoismcneil at 2007-6-29 11:25:47 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...
# 2
Please read the following site http://java.sun.com/security/ssl/API_users_guide.htmlIstikhar
istikhar99 at 2007-6-29 11:25:47 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...
# 3

Please read the following site

http://java.sun.com/security/ssl/API_users_guide.html

http://www.securingjava.com/chapter-three/chapter-three-2.html

http://www.oadg.or.jp/activity/mncrs/mobcomm/fwt/doc/API_users_guide.html

If u r require a sample program then you can find in the

samples\sockets directory of the JSSE installations

Istikhar

istikhar99 at 2007-6-29 11:25:47 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...
# 4

You could use the JCE cryptography classes to physically encrypt your byte streams before sending them, and then decrypting them upon receiving. You should be able to hack these classes into a JDK1.1.x app. Of course the real problem will be that it won't be portable, and will probably not work if you ever upgrade to 1.2 without rewriting it.

You could also do something very simple, like writing your own 'secret decoder ring' type stuff. Basically take the data you are going to send, mutate in some predictable fashion like adding 3 bytes to each character or sending the stream in reverse order, and then reversing the process upon receipt. Obviously this method isn't very cryptographically strong, but should serve its purpose. I can't imagine you are in a high $ production environment still running JDK 1.1.x.

ctmoore at 2007-6-29 11:25:47 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...
# 5

I was faced with the same problem. I had to communicate securely from within Microsoft IIS application that was calling some java APIs. Microsoft uses old JDK 1.x so I had to do some research.

It is true that JSSE requires JDK 1.3.1. But you can run RMI client from old JRE 1.x that is calling RMI server. RMI server has socket pool of some sort and acts as SSL client. This server is running on JRE 1.3 or later as recommended by SUN. RMI server talks to JRE 1.3 SSL server. Everything works like a charm. I was able to send millions of messages in the stress test mode running hundreds of simulated users.

You can also use serialazation instead of RMI and any other of inter process communication (EJB, CORBA) depends on your architecture. You must run JDK 1.x application and RMI server on the same box so nobody can snoop on your trtaffic.

If you don't like his approach you can try some third party products from:

http://www.phaos.com or http://www.certicom.com. I have not tried any of these products but the sales people claim that they support JDK 1.x and later.

Hope it helps, Kris.

kgemborys at 2007-6-29 11:25:47 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...