# Re: SSL-HTTPS Java Web Server - Help Needed

David Brownell (David.Brownell@Eng)
Fri, 12 Jun 1998 15:18:09 -0700

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Previous message: Richard D. Brown: "SSL-HTTPS Java Web Server - Help Needed"
- Maybe in reply to: Richard D. Brown: "SSL-HTTPS Java Web Server - Help Needed"

    Date: Fri, 12 Jun 1998 15:18:09 -0700

    From: David.Brownell@Eng (David Brownell)

    Message-Id: <199806122218.PAA01040@argon.eng.sun.com>

    To: java-security@web3.javasoft.com, rdbrown@GlobeSet.com

    Subject: Re: SSL-HTTPS Java Web Server - Help Needed

> From: "Richard D. Brown" <rdbrown@GlobeSet.com>
> To: "'java-security@java.sun.com'" <java-security@web3.javasoft.com>
> Cc: "'rdbrown@globeset.com'" <rdbrown@GlobeSet.com>
> Subject: SSL-HTTPS Java Web Server - Help Needed
> Date: Fri, 12 Jun 1998 15:35:26 -0500
>
> Hello,
>
> I should have missed something ...
>
> Before getting to the problems raised by the solution envisioned for
> solving an earlier problem, let talk about the original objective.
>
> We are willing to build a monitor that is able to establish (client) or
> accept (server) HTTPS connections (HTTP1.1, SSLv3). The SSLv3 handshake
> (with client authentication) shall be enhanced in that the certificates
> chain of the peer shall be further verified and authorized by accessing a
> LDAP directory service (v3 compliant).
>
> At a first look, it seems that a Java Web Server (+extensions) has all the
> components that we are looking for: HTTP 1.1 protocol handler, SSLv3
> sockets (client and server), LDAPv3 client (JNDI).

Right, except that the URL handler isn't HTTP/1.1 compliant.

The Java Web Server supports HTTP/1.1, but there's a gap on
the client side (JDK code). At this point in the deployment
of HTTP/1.1 it's wise to commonly expect HTTP/1.0 clients.

For reference, this "tie LDAP into certificate based authentication"
was a design requirement for the Java Web Server, and all the
functionality to provide it was available in the 1.0 release
(barely over a year ago).

> At a second look, everything is getting a little bit more confusing. It
> seems that being able to supervise the handshake (client or server side)
> requires programming at the SSL socket level by setting up a handshake
> completion event listener and/or retrieving certificate information from
> the SSL session that is accessible from the SSL socket.

Not quite -- the handshake doesn't complete unless the peer's cert
chain was already accepted for authentication purposes.

There's an API that manages that decision, but it's currently not
public: sun.security.TrustDecider is the class, and the method is
"isTrustedFor()". Takes a cert chain, a purpose (in this case, SSL
authentication), and a date (to support cert validity checks for
times other than "right now", as well as speed things up).

The deal is that the implementation of that method provides all
the policy for what CAs and certs are trusted. It would handle
X509V3 attributes, obeying a policy such as PKIX or straight X509.

In your case, that'd also use JNDI to go to the LDAP server.

In other cases, it might check a CRL to see if the cert's valid.

... however, I think you still need a source license to get access
to those APIs.

> Programming at the SSL socket level raises at least two questions:
>
> 1 - a SSL socket does not implement any particular protocol (http, ftp,
> ...). It offers only an SSL-TCP stream. So, how do I benefit from the HTTP
> 1.1 protocol handler built in the server?
>
> 2 - the SSL server socket is actually instantiated and managed by the web
> server. So, how do I get access to this socket for enabling a handshake
> completion event listener?

See above -- what you do is plug in to the authentication subsystem
by providing a new trust decider. You're not talking to SSL sockets,
so these concerns don't arise.

> At a third look, it appears that if the JVM is SSL enabled then an HTTPS
> protocol handler shall be recognized and, therefore, regular programming
> through Url and UrlConnection shall work just fine (for the Client). This
> however raises a new problem. How do I retrieve further information about
> the peer from a UrlConnection?

Those java.net interfaces don't offer a way to do this, but again it's
possible if you use "sun.*" APIs to access the HttpsURLConnection.
There's a getServerCertificateChain() method there.

> A similar problem needs to be addressed on the server side; How could a
> servlet access certificate information whenever connection happens through
> SSL with client authentication?

There's a public API for this one:

javax.security.cert.X509Certificate certs [];

certs = javax.servlet.ServletRequest.getAttribute (
"javax.net.ssl.peer_certificates");

One would then use these certificates for authorization decisions.
Perhaps there's a V3 attribute used to identify role; or the
LDAP server (not the CA!) manages such information (to avoid any
routine need to revoke certificates as users' authorizations change).

> I've been looking around for quite a while and I can't figure my way out.
> Has anybody experience in this matter? Help surely appreciated.

It'll help when the authentication APIs finally get exposed. All
of the other APIs you need to deliver this functionality are public
and fully supported.

- Dave

> Thanks,
>
> Richard D. Brown GlobeSet, Inc.
> Senior System Architect 1250 S. Capital of Texas Hwy.
> Phone: (512)427-5173 Building 1, Suite 300
> Fax: (512)427-5101 Austin, Texas 78746
> mailto:rdbrown@globeset.com http://www.GlobeSet.com
>
>

- Previous message: Richard D. Brown: "SSL-HTTPS Java Web Server - Help Needed"
- Maybe in reply to: Richard D. Brown: "SSL-HTTPS Java Web Server - Help Needed"