# RE: Applets opening sockets using Java Plug-in 1.1 on WinNT with IE4

devnull@ad1440.net
Thu, 9 Jul 1998 11:45:29 -0700 (PDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: schemers@Eng: "Re: Changing classloader of a class"
- Previous message: Charlie Lai: "Re: can frames be used in trusted applets"

    From: devnull@ad1440.net

    Date: Thu, 9 Jul 1998 11:45:29 -0700 (PDT)

    To: "Bishop, Cindy" <cbishop@securitydynamics.com>

    Subject: RE: Applets opening sockets using Java Plug-in 1.1 on WinNT with  IE4

    In-Reply-To: <D104150098E6D111B7830000F8D90AE8151A7A@exna02.securitydynamics.com>

On Thu, 9 Jul 1998, Bishop, Cindy wrote:

> I'm wondering if IE accepts the certificate format you're signing your
> applets with? I had some trouble using JavaKey vs.
> the Netscape Object Signing tool (zigbert). Sometimes the signing cert is
> considered invalid. What does IE do when your applet tries to load?
> -or are you only using a plug-in now?

IE by itself accepts the certificates fine, as far as I can tell. IE with
plugin does not, it seems. Nor does netscape with plugin (on the PC,
anyway. Netscape with plugin works great on Unix). I've now resorted to
using HotJava on the PC, and it seems that IT doesn't like the certificate
either -- it treats my signed applet as an unsigned applet. At this
point, I'm thinking this is a bug in the PC version of the JDK.
I'm next going to try downloading and installing the PC version of
the JDK and making a certificate with that and seeing if it works on both
platforms.
I'm STILL looking for that elusive flag to disable the checkListen
security for port 162.

> > ----------
> > From: devnull@ad1440.net[SMTP:devnull@ad1440.net]
> > Reply To: devnull@ad1440.net
> > Sent: Thursday, July 02, 1998 12:25 AM
> > To: Seattle Java Users Group; Advanced Java
> > Cc: java-security@java.sun.com; java-plugin-feedback@sun.com
> > Subject: Applets opening sockets using Java Plug-in 1.1 on WinNT with IE4
> >
> >
> > I have an applet that opens a socket on port 162 to listen for
> > SNMP traps. In order to use this, users usually have to disable applet
> > security for this in their browser. Recently (yesterday), we started
> > using the Java Plug-in to get our product working on Netscape, etc. since
> > we use JDK1.1.x
> > The plug-in seems to have it's own security system which
> > essentially bypasses the browser's built-in security so that any settings
> > on the browser no longer apply to the applet. In order to work around
> > this, I decided to use the signing features available with javakey, etc.
> > even though this requires users to either have their own javakey program
> > or to download a file called identitydb.obj into their home directory
> > (possibly blowing away other files of same name that they downloaded for
> > other trusted applets, or vice versa and thereby causing great headaches
> > to users and programmers alike). It seems that this is the only way to
> > get around security features that the plug-in has.
> > So far so good. I'm not too upset by this because I've been
> > meaning to get around to signing my applet sooner or later anyway, and at
> > the same time, it required me to go to a jar file format, which is
> > inherently better anyway. So the tradeoffs are slightly in favor of doing
> > this anyway.
> > Well, lo and behold, the applet runs under netscape without a
> > hitch. Once the user puts the correct identitydb.obj file in their home
> > directory and does the plug-in FAQ's workaround bug of setting the plugin
> > arguments to have
> > -Dappletviewer.security.mode=unrestricted
> > (a large hole, but they say they'll fix in next version of plugin, so I
> > have to live with it...*grumble* *gripe*).
> > HOWEVER, under IE, in which my applet used to work (albeit with
> > some major bugs -- which is why we are going to the plug-in, to provide a
> > consistent JVM across platforms), it now generates a security exception
> > when the SNMP library tries to open a socket to listen on port 162.
> >
> > sun.applet.AppletSecurityException: checkListen
> > at java.lang.Throwable..<init> (Compiled Code)
> > at java.lang.SecurityException.<init> (Compiled Code)
> > at sun.applet.AppletSecurityException.<init> (Compiled Code)
> > at sun.applet.AppletSecurityException.<init> (Compiled Code)
> > at sun.applet.AppletSecurity.checkListen(AppletSecurity.java:480)
> > at java.net.DatagramSocket.create(DatagramSocket.java:125)
> > at java.net.DatagramSocket.<init>(DatagramSocket.java:114)
> > at java.net.DatagramSocket.<init>(DatagramSocket.java:125)
> > at Snmp.SnmpSession.open(SnmpSession.java:137)
> > at WebCNM.TrapListener.init (Compiled Code)
> > at WebCNM.Webnms.init (Compiled Code)
> > at sun.applet.AppletPanel.run (Compiled Code)
> > at java.lang.Thread.run (Compiled Code)
> >
> > Well, that's sort of fine -- at least I know the Security Manager
> > is doing it's job. However, for other such problems, there are ways to
> > have the user disable these security features. For example, to allow them
> > to write to files, I would simply tell them to put
> > -Dacl.write=/ in their plug-in parameters line (or the NT equivalent if
> > theyre on NT).
> > After exhaustive searching through FAQ's, etc, I cannot find a way
> > to disable the part of the security manager that controls the ports a user
> > can listen on.
> > What's even more frustrating is that this problem only occurs on
> > IE. (although I haven't yet tested Netscape on PC's, I have tested it on
> > Solaris, and it does not have this problem -- it freely opens the SNMP
> > trap port with nary a quibble as long as my applet is signed and
> > "trusted". The same behavior with appletviewer and HotJava (on
> > Solaris). I'm about to try it with netscape on the PC to determine if
> > this is a plugin platform difference or whether this is due to just IE).
> > I'm not sure whether this security is intentional or overlooked,
> > but I think that if my applet is trusted, it should be able to do what it
> > wishes. If that is not to be policy, then whatever policy it ends up
> > being should be consistent across platforms. In addition, there should be
> > a documented way to override parts of the Security Manager, such as there
> > is for acl.write and acl.read and system properties. I suspect that a
> > simple flag DOES exist to allow me to get past this, but I cant find it
> > documented anywhere.
> >
> > If anyone knows of this elusive flag to allow applets to bypass
> > the checkListen method and listen on socket port 162, please tell me. At
> > this point, I'm desperate.
> >
> > Thanks greatly in advance.
> >
> > ==========================================================================
> > ====
> > lwilson@bridgeway.com S/W Developer
> > http://www.bridgeway.com
> > devnull@ad1440.net Webmaster
> > http://www.ad1440.net/~devnull
> > ==========================================================================
> > ====
> > Don't Anthropomorphize Computers -- They Really Hate That...
> >
> >
> >
> > Unsubscription, archives, FAQ - http://www.xcf.berkeley.edu/lists.html
> >
>

==============================================================================
lwilson@bridgeway.com S/W Developer http://www.bridgeway.com
devnull@ad1440.net Webmaster http://www.ad1440.net/~devnull
Home:206-527-5901 SysAdmin Office:425-881-4270 x 165
==============================================================================
Don't Anthropomorphize Computers -- They Really Hate That...

- Next message: schemers@Eng: "Re: Changing classloader of a class"
- Previous message: Charlie Lai: "Re: can frames be used in trusted applets"