← Back to team overview

openjdk team mailing list archive

[Bug 199680] Re: Java applets do not work under SSL/HTTPS

 

Hi

I finally discovered what is the issue here. In appears that in case of
unsigned applets, the code is unable to access SunJCE provider which
contains most of the ciphers used by SSL protocol. This means that a
session with SSL server is broken and effectively applet is not
initialised.

This problem is related to configuration of JRE under linux due to
export control restrictions. Unfortunately I don't know how to make JRE
to use SunJCE by default.

As a workaround I have set up the following policies using Policy
Manager:

grant {
  permission java.security.SecurityPermission "putProviderProperty.SunJCE";
};

grant {
  permission java.lang.RuntimePermission "getProtectionDomain";
};

grant {
  permission java.lang.RuntimePermission "accessClassInPackage.sun.security.*";
};

I don't know how insecure my actions are, but this definitely fixed
problems with applets under SSL / HTTPS.

Feel free to send me your ideas how to fix this issue in more elegant
way.

Best,
Marcin

-- 
Java applets do not work under SSL/HTTPS
https://bugs.launchpad.net/bugs/199680
You received this bug notification because you are a member of OpenJDK,
which is subscribed to icedtea-gcjwebplugin in ubuntu.

Status in “icedtea-gcjwebplugin” source package in Ubuntu: Incomplete

Bug description:
Binary package hint: firefox

Trying Suns java 5 & 6, Iced tea as well as plain GCJ. None of them work with applets under SSL (https). Normal http applets load just fine.

Hardy, updated as of 2008-03-08. Intel, 32 bit. Several people have this problem, see: http://ubuntuforums.org/showthread.php?t=718018 for more info.

The actual places it happens to me live are URL:s I can't disclose, but these googled URLs seem to exhibit the same behaviour:

https://jadc.dev.java.net/
https://jogl-demos.dev.java.net/applettest.html

Which is, "Start: applet not initialized." and nothing more happening. It's the same for all the plugins. Plain HTTP works fine.

Bug #157721 might be related, but it seemed too uncertain.