United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6424631 Signed applet hangs browser if a remote policy server is being used
JDK-6424631 : Signed applet hangs browser if a remote policy server is being used

Details
Type:
Bug
Submit Date:
2006-05-11
Status:
Closed
Updated Date:
2012-06-21
Project Name:
JDK
Resolved Date:
2006-09-29
Component:
deploy
OS:
solaris_10,windows_xp
Sub-Component:
plugin
CPU:
x86,sparc
Priority:
P2
Resolution:
Fixed
Affected Versions:
5.0u6,6
Fixed Versions:
5.0u10 (b02)

Related Reports
Backport:
Backport:
Duplicate:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
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.

                                    

Comments
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
                                     
2006-07-25
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.
                                     
2006-07-27
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.
                                     
2006-08-28



Hardware and Software, Engineered to Work Together