JDK-8032676 : RDF (8029649) can cause performance problem when Revocation check times out.
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 7u55,8u5
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-01-24
  • Updated: 2014-10-15
  • Resolved: 2014-02-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 JDK 9
7u55Fixed 8u11Fixed 9Fixed
Related Reports
Relates :  
JDK-8029649 - Reduce dialog frequency when app is run multiple times
Relates :  
JDK-8032631 - It takes a long time to load sandbox app after accepting a multi-click dialog caused by "the certificate revocation site cannot be accessed"
Description
When a cert is accepted, https://bugs.openjdk.java.net/browse/JDK-8029649 causes the decision to be remembered for a short time.  When a new browser session runs the same app again, the certificate dialog will not be shown, and the app will run, however, the certificate is not placed in the session store, which can cause subsequent jars signed by the same cert to go thru revocation checking, and if revocation checking times out (cannot reach revocation server) this can take a long time.
The requirements for JDK-8029649 prohibit us from adding cert to session stores, since only that exact app (not other apps signed by the same cert and from the same domain) may be run skipping the cert dialog due to the remembered decision
Comments
SQE OK
13-03-2014
7u60 critical request: This RDF bug fix needs to be ported to 7u60 as part of the Release Team request to port the Reduce Dialog Frequency feature to 7u60 for Early Access testing
13-03-2014
SQE OK to take the featre related fix into CPU14_02. There were no new failures detected in Plugin during nightly testing.
03-02-2014
critical request - related to Reduce Dialog frequency enhancement. Review complete, fix in 8u/7u open repos.
03-02-2014
the problem can be demonstrated by the testcase in: https://bugs.openjdk.java.net/browse/JDK-8032631 with proxy set to none (from within OWAN), the applet: http://sqeweb.us.oracle.com/net/sqenfs-1/export1/comp/jsn/users/crystal/DO_NOT_REMOVE_ME/jrebug/OcspAndCrlCheck/html/testFailToAccessCerRevoSite_SB.html will take several minutes to start (since revocation checks time out). You will see two RevocationStatusUnknown exceptions in the console, then security dialog shows up - accept it. Now, without this fix, if you run the same app within one day in a new browser session, you will see 6 RevocationStatusUnknown exceptions in the console, and app will start without showing dialog again but will take 3 times as long. This is because it is checking the revocation status on two additional jars, signed with the same cert. After the fix, on the second time you run the app, you will only see 2 exceptions (like the first time) and applet will then start. webrev: http://oklahoma.us.oracle.com/www/webrevs/aherrick/1.7.0_55/8032676/ webrev is against 7u55, but identical change in TrustDecider.java applies to 8u5 as well. Crucible review: https://java.se.oracle.com/code/cru/CR-JDK8UCPU-44
31-01-2014
The fix to add a certificate store of those certs already checked for revocation in this session is quite simple,
29-01-2014
There is inconsistency in the existing behavior and requirements for RDF feature: 1.) When a certificate (for a all-perm or sandbox jar) is displayed to the user and accepted it is placed in the session store (or sandbox session store). This means any other jar, either of the same app or a different one, that is signed by the same certificate, and if app resides on the same collection of domains, will be passed in the session without dialog (and without re-revocation checking the cert chain). 2.) RDF: When an app has been run, in different browser session within the past 1 day (or 7 days if https), if app is unchanged, certificate dialog will not be shown. Because the requirements say exact same unchanged app, the cert is not placed in the session store, as it would be if the dialog were shown again in this session and accepted. Otherwise, other apps signed by the same cert would be free from the dialog as well. As a side effect of not placing the cert in the session store, subsequent jars in the same app, signed by the same cert, will undergo revocation checking, causing this performance regression. We can either change requirements and allow cert to be placed in session store at this point, or create some form of revocation check completed session store, or implement CRL and OCSP caching (as requested in https://bugs.openjdk.java.net/browse/JDK-8032676)
24-01-2014