Bug ID: JDK-6424631 Signed applet hangs browser if a remote policy server is being used

Type: Bug
Component: deploy
Sub-Component: plugin
Affected Version: 5.0u6,6

Priority: P2
Status: Closed
Resolution: Fixed
OS: solaris_10,windows_xp
CPU: x86,sparc

Submitted: 2006-05-11
Updated: 2012-06-21
Resolved: 2006-09-29

Other	JDK 6	JDK 7
5.0u10 b02Fixed	6u1Fixed	7Fixed

Java Plugin 1.5.0 U6, Solaris and Windows
When policy use is enforced in java.policy

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

      AND 

a remote policy server is specified in java.security:

policy.url.2=https://aubing.germany/ourpolicy.policy

which grants an applet write permissions:

grant codebase "https://aubing.germany/writeFileApplet/writeFileApplet.jar"
{
   permission java.io.FilePermission "<<ALL FILES>>", "read,execute,write";
   permission java.util.PropertyPermission "user.home", "read";
};

THEN we see 

- an AccessControlException on WinXP/IE
- a hang on Solaris/Firefox (Applet is being loaded)


If the SAME write permissions

grant codebase "https://aubing.germany/writeFileApplet/writeFileApplet.jar"
{
   permission java.io.FilePermission "<<ALL FILES>>", "read,execute,write";
   permission java.util.PropertyPermission "user.home", "read";
};

are specified in the java.policy file AND the remote policy server is
disabled in java security, THEN all is fine.

Side note: The root certificate is being stored as trusted CA in the browser
keystore and the browser keystore is being used.

EVALUATION Current implimentation do not initialize policy upfront. Instread, it initializes the policy after attempting to load security provider and it ends up in recursion while reading on HTTPS. New security provider loading implimentation should initialize policy before actually attempting to load a provider like JCE.

28-08-2006

SUGGESTED FIX Another minor fix also needs to go into the deploy workspace to allow Firefox on Windows to correctly load the JSS security implementation. That may be filed as a separate bug.

27-07-2006

SUGGESTED FIX The following loop is encountered, preventing policy from getting loaded over HTTPS in certain circumstances: 1. load security provider 2. signed provider (like JCE) causes security check 3. init policy 4. policy attempts to load over HTTPS 5. HTTPS code calls Cipher.getInstance 6. Cipher.getInstance loads security providers 7. provider loading code detects recursion, exits 8. HTTPS policy (step 4) unable to be loaded To fix the problem, the security provider loading mechanism should be changed to trigger policy initialization up front (before actually attempting to load a provider). This results in the following logic: 1. load security provider 2. trigger policy initialization 3. init policy 4. policy attempts to load over HTTPS 5. HTTPS code calls Cipher.getInstance 6. Cipher.getInstance loads security providers 7. trigger policy initialization 8. init policy 9. detect recursion in policy implementation, install bootstrap policy 10. policy initialization (step 8) succeeds 11. steps (6), (5), (4), (3), (1) succeed as recursion unwraps The only time we don't want to trigger policy initialization is during signed jar verification. If policy initialization IS triggered in that case, we end up with: 1. load class from signed jar (like firefox's jss.jar) 2. verify jss.jar 3. jar verification code installs thread providers (SUN and rsaSign) 4. load thread providers 5. trigger policy initialization 6. init policy 7. policy loads over HTTPS 8. HTTPS code calls Cipher.getInstance 9. Cipher.getInstance fails because thread providers do not support needed functionality 10. HTTPS policy (step 7) unable to be loaded The proposed fix ensures that when jar verification is performed, the logic remains as before: 1. load class from signed jar (like firefox's jss.jar) 2. verify jss.jar 3. jar verification installs thread providers (SUN and rsaSign) 4. load thread providers (no signed providers, so no policy initialization) 5. jar verification succeeds Separate from this is another loop that starts in plugin: 1. plugin creates HTTPS URL object 2. com.sun.deploy.net.protocol.https.Handler (HTTPS stream handler) constructor is invoked 3. Handler calls registerSecurityProviders 4. load security providers 5. trigger policy initialization 6. init policy 7. policy attempts to load over HTTPS 8. policy creates HTTPS URL 9. (obselete) sun.plugin.net.protocol.https.Handler (HTTPS stream handler) constructor is invoked 10. class not found (deleted sometime before 5.0 release) 11. fall back to default SSL context (uses cacerts and jssecacerts truststores) 12. HTTPS policy (step 7) unable to be loaded because server cert not installed in cacerts nor jssecacerts An additional fix (combined with those above) involves plugin triggering policy initialization prior to creating the HTTPS URL object. The resulting flow then becomes: 1. plugin triggers policy initialization 2. init policy 3. policy attempts to load over HTTPS 4. policy creates HTTPS URL 5. com.sun.deploy.net.protocol.https.Handler (HTTPS stream handler) constructor is invoked 6. Handler calls registerSecurityProviders 7. load security providers 8. trigger policy initialization 9. init policy 10 detect recursion in policy implementation, install bootstrap policy 11. policy initialization (step 9) succeeds 12. steps (7), (5), (3), (2) succeed as recursion unwraps 13. plugin creates HTTPS URL object 14. com.sun.deploy.net.protocol.https.Handler (previous constructed in step 5) is used

25-07-2006

Duplicate :	JDK-6495732 - Policy keystore recursion problem loading SunMSCAPI provider
Relates :	JDK-7093090 - Reduce synchronization in java.security.Policy.getPolicyNoCheck
Relates :	JDK-2224385 - Reduce synchronization in java.security.Policy.getPolicyNoCheck
Relates :	JDK-6895411 - Regression: Applets are not honoring the remote policy URL
Relates :	JDK-7169257 - Fix for 6424631 only partially ported to JDK 7 & JDK 8