Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4268582

Request for plugin enhancements

    XMLWordPrintable

    Details

    • Type: Enhancement
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: 1.2.1
    • Fix Version/s: 1.4.0
    • Component/s: deploy
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      beta2
    • CPU:
      generic
    • OS:
      solaris_2.6

      Description

      Hi,
      My name is Chihong Liang. I'm a colleague of Lily Chang's at SUN Java
      Center
      New York office, who put in this service order.

      It appears to me our request is a "feature enhancement" of the Java
      Plugin.
      Description as follows:

      More than one clients of the Java Center here want to run applets in the
      Java Plugin. Typically they want to do the following:
        1. Run HTTPS server on firewall
        2. Setup enterprise applications running behind the firewall
        3. Deploy GUI front-end applets on user desktop outside the
           corporate firewall. Applets will be running in Java Plugin.
        4. Install client certificate (issued by a CA like GTE or Verisign,
           for example) in the browsers
        5. Applets will be using HTTPS tunneling to pass thru the HTTPS
           server to connect back to whatever enterprise applications
           behind the firewall. SSL communication channels are established
           between the applets and the HTTPS server, mutual authentication
           is required (instead of just doing server authentication with
           regular SSL sessions).


      Here is what the current versions of Java Plugin could do in terms of
      security, authentication and SSL:
         - it will utilize the HTTPS connection implemented by its
           underlying browsers.
         - it currently relies on the underlying browser to handle
           certificates and authentications. After a user installs a
           certificate he/she obtains from a root CA (i.e. Verisign),
           the browser will use that to authenticate itself to remote
           server. If the authentication is successful, an SSL
           channel is established. The Java Plugin, thru JRE, will
           simply expose that as an URLConnection to applets.
           Applet developers have no way of accessing the user
           certificate except using that URLConnection.


      Here comes the problem:
         - there are situations when an applet can NOT reply on using
           the default HTTPS implementation of browsers. In some cases
           developers want to import a client certificate from a
           browser and perform mutual authentication with remote
           servers directly inside the applet code space.
         - certificate information is installed in a browser-dependent
           format/location/way. It 's impossible for an applet to
           retrieve/import that piece of information in a portable
           way thru pure Java code. Only the Java Plugin, which has
           access to native browser APIs, would possibly be able to
           import certificates from the underlying browsers and
           expose them to applets in some Java interface to be used
           for security purpose.

      Here 's what we would request:
           direct support of client authentication in Java Plugin,
           (instead of thru the browser 's support), in terms of
           the following:
             - import of client certificates to the JRE/Plugin
               space from the browser space
             - exposure of client certificates thru the java
               security framework so developers could query what
               are the certificates currently installed/enabled
               in the current JRE of the plugin.

      We understand this as a non-trivial effort that might
      require synergetic work from the java plugin team as well as the
      security team. If someone could investigate further on the
      issue, it would be of tremendous help to our business clients.


      I think I should amend the request I sent to you for service order
      #4127739.

      In my previous mail I just describe the reason why we hope for some
      enhancement of the Java Plugin to deal with client authentication using
      user certificates embedded in browsers. This enhancement, if
      implemented,
      will help developers retrieve and use client certificates inside the
      applet code space in an 100% pure Java, browser-independent way.

      However, this doesn't solve our clients' problem completely. For
      whatever reasons they are betting heavily on JSSE, the Java Secure
      Socket Extension, a product which is currently in pre-beta stage.
      JSSE is basically a Java implementation of SSL. Supposedly it could
      be used to establish a secure communication between a client and
      a server. However currently its built-in HTTPS handler doesn't
      provide convenient facility for enabling client authentication (in most
      of the HTTPS connections today, typically only server authentication
      is required). I have talked to one JSSE team engineer named
      Jeff Nisewanger regarding this issue and he mentioned some sort
      of plan on improving the HTTPS handler in JSSE to make processing
      client authentication possible. However there is no definite timeframe
      for the availability of a new JSSE release. We think the following
      features are important and useful and would like to request for
      an investigation so they could be made available sooner:
        - an HTTPS handler implementation that could utilize a
          customized SSLSocket configured with user certificates
          so that client authentication could be done
        - 40 bit encryption instead of 128 bit strong encryption,
          for concerns of U.S export regulation


      In conclusion, only the enhancement of the Java Plugin and the
      improvement
      of JSSE together will complete the picture of performing client
      authentication
      in applet space in a portable way. Thanks a lot for your attention to
      this matter.

        Attachments

          Activity

            People

            Assignee:
            dgu Dennis Gu (Inactive)
            Reporter:
            rletteri Robert Letteri (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: