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