Date: Thu, 11 Jun 1998 15:51:48 -0700
From: David.Brownell@Eng (David Brownell)
Message-Id: <199806112251.PAA28792@argon.eng.sun.com>
To: Jack.Donn@digital.com
Subject: Re: Technical Question: SSLSocket Class versus SSLSocketImpl Class
Sorry for the delayed response here ...
Some of the reasons that "SocketImplFactory" is inappropriate
include:
* It was designed as glue over Berkeley's C Sockets API,
not for use by 100% Pure Java code. Look at those
details of the SocketImpl class, and how different they
are from Socket, ServerSocket, and DatagramSocket.
* Replacing the default version means you've then got to
provide your own way to get to network hardware, since
you will have replaced the JVM's standard way to access
such devices (native code). Basically, this requires
use of native methods.
* That's a VM-wide policy, so what you suggest would make
every socket call try to use SSL (presumably over TCP),
even when talking to servers that don't support SSL (or
which only turn on SSL after specific requests).
* To use that mechanism, your code must have privileges
which are strictly irrelevant to the problem of getting
SSL connectivity. The "least privilege" principle argues
against requiring privileges to set that factory (or to
load native code).
The last time we checked, nobody had successfully used any part of the
SocketImplFactory mechanism except to customize the native code
providing access to the networking stack(s).
In contrast, the SocketFactory (and ServerSocketFactory) APIs were
designed as a general approach to enable new sorts of connection
oriented stacks to be implemented as 100% Pure Java.
SSL is one kind of "secure channel", and there are others. I've
implemented "record stream" protocols (vs byte stream, like TCP), and
"compressed channels". There are ways to encapsulate a wide variety of
firewall tunneling strategies in SocketFactory objects; for example,
going direct, using several tunneling protocols, encrypting, auditing,
and so on.
In short, the SocketImpl stuff isn't very useful except to parts of the
JVM implementer/porter community. It's not useful as a generic
networking facility.
- Dave
> From Jack.Donn@digital.com Tue Jun 2 17:55:06 1998
> From: Jack Donn <Jack.Donn@digital.com>
> To: "'java-security@java.sun.com'" <java-security@web2.javasoft.com>
> Subject: Technical Question: SSLSocket Class versus SSLSocketImpl Class
> Date: Tue, 2 Jun 1998 20:53:41 -0400
>
> I am new to the java.net package and have downloaded your ssl api. I have
> been looking at the jdk1.1 documentation on SocketImpl, the static
> setSocketImplFactory method of Socket and the corresponding static method
> for ServerSocket.
>
> At first glance it would appear that the intent for a specialized socket
> implementation such as SSL socket would be:
>
> - create SSLSocketImpl Class ( rather than the SSLSocket Class)
> - create SSL SocketFactory with createSocketImpl() yielding new
> SSLSocketImpl() instance
> - Socket.set SocketImplFactory(..result of create above..)
> - then do normal new ServerSocket() and new Socket()
>
> Clearly this isn't the way the api classes are built (and I am sure for good
> but not apparent to the novice reasons). I would greatly appreciate a
> deeper understanding of the reasons.
>
> Sincerely, Jack Donn
>
> ===============================
> Jack J.Donn
> Diagnosis Tools Engineering Group
> Product Service Engineering
> 719-592-5112 - DTN 592-5112
> jack.donn@digital.com
> <<...>> Digital Equipment Corporation
>