3 Replies Latest reply on Jul 2, 2014 2:11 PM by a2d92766-d905-495e-8be3-da56b48cce7e

    Regression in 7u55+ prompts for authentication dialogs (JDK-8046211)

    user10960148

      I'm tracking issue JDK-8046211 and noticed today it was resolved as "won't

      fix" without any comment

       

      Our situation: We have a Java applet consisting of 4 jar files and a JNLP

      file. These files are served over HTTPS from a public webserver (no

      authentication required). The applet contains an up-to-date manifest with

      all the entries required since the new Java security baseline. The

      applet/JNLP file is accessed from a web application using Javascript

      (deployJava.js). All interaction with the applet is through Javascript.

      The web application itself runs on a different server and is protected

      using client certificates (2-way SSL) and basic authentication.

       

      Now until Java 7u55 everything worked fine. When loading the applet only

      one popup was displayed asking the user to trust the applet (which is

      properly signed) and that was all.

       

      However since 7u55 (also 7u60) things have changed: the applet loads fine

      but as soon as we call a method on the applet (though LiveConnect) the Java

      VM displays a popup asking the user to select a client certificate and

      thereafter asks the user to authenticate using BasicAuth.

       

      Important note: the user doesn't actually has to select a valid certificate

      or enter any credentials. If the user cancels any of the dialogs the applet

      continues to function properly. Logging shows the applet is using the same

      cookie as the browser so authentication against the server isn't actually

      taking place. Basically the Java VM is prompting for authentication dialogs

      for no good reason because the user is already authenticated with a browser

      cookie.

       

      Prior to 7u55 we didn't experience this issue (we have users with 7u40,

      7u45 and 7u51). Altogether it appears we encountered JDK-8046211, which has

      the characteristics of a regression issue.

       

      I'm curious if more people have experienced these issues (I know applets aren't the hottest tech out there....)

        • 1. Re: Regression in 7u55+ prompts for authentication dialogs (JDK-8046211)
          833f4912-60ce-4925-9a49-edb31f8b57b6

          Same problem with our app with:

          7u55, 7u60 and 8u5

          Our configuration is almost as yours:

          - applet taken through https with "simple server auth" (no client auth neither required or optional)

          - from within an html page distributed under https with client auth (no parallel basic auth in our case)

          - applet manifest in up-to-date (7u55+ compliant)

          Extra certificate popup comes from the fact that JPI is requesting a client auth protected web context by its own, in parallel to the already client auth protected webbrowser connection.

          • 2. Re: Regression in 7u55+ prompts for authentication dialogs (JDK-8046211)
            833f4912-60ce-4925-9a49-edb31f8b57b6

            We have the same problem as you.

            Problematic JRE versions are 7u55, 7u60 and 8u5.

            Problematic browsers are at least IE10, IE11 and Firefox 29 (with an extra security warning window in our case, as our certificate chains are provisioned in the system truststore but not in the JPI/JRE truststores)

            Our architecture is pretty close to yours:

            - applet with"free" https codebase

            - from within a client auth protected https page

            Problem seems to come from the fact that JPI is performing an extra https request against the client auth protected web context by its own at load time.

            • 3. Re: Regression in 7u55+ prompts for authentication dialogs (JDK-8046211)
              a2d92766-d905-495e-8be3-da56b48cce7e

              Yes the problem is due to an extra HTTP call fired from the Java plugin (only under IE, no issues in Firefox) to the page that embeds the applet. So it's different from JDK-8046211 although the result is the same.


              We eventually implemented a workaround: we intercept the extra HTTP request in our frontend proxy server (Apache) and always return 200 OK prior to doing BasicAuth. Here's our mod_rewrite config implementing this workaround:

              RewriteEngine On

              RewriteLog /var/log/apache2/java_issue_rewrite.log

              RewriteLogLevel 0

              RewriteCond %{REQUEST_METHOD} =GET

              RewriteCond %{HTTP_USER_AGENT} Java/1.[7-8]

              RewriteRule ^/path/to/page/embedding/java/applet /dummy.html [R=200,L]