# Re: http://java.sun.com/security/ssl/API_users_guide.html

David Brownell (db@Eng)
Mon, 14 Dec 1998 12:43:44 -0800

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Jan Luehe: "Re: Bug report"
- Previous message: Jan Luehe: "Re: Using signed applets with java plugin - clarification"
- Maybe in reply to: Life is hard, and then you die.: "http://java.sun.com/security/ssl/API_users_guide.html"

"Life is hard, and then you die." wrote:
>
> Hi,
>
> Is there any archive of any discussions on this API?

No ...

> Anyway, I have the following problem with the current spec: how do I
> create a plain Socket, talk some protocol (such as SOCKS5, HTTP CONNECT,
> whatever) to establish a tunnel through a proxy, and then start the SSL
> handshake? For the life of me, I can't figure out how this can be
> achieved with the current API. But this is a pretty standard requirement.

See this URL for the currently planned APIs:

http://www.oadg.or.jp/activity/mncrs/mobcomm/fwt/doc/index.html

Unfortunately, I don't know when the next release of the SSL package
will be forthcoming. It should include such support. An API like the
one you suggest below could also be used, or else layering the secure
sockets "Layer" on top of some existing "pre-tunneled" socket. Some
sorts of protocols want explicit control over the SSL "layer" (e.g. to
stop encrypting traffic, yet continue using the connection) so I've got
a preference for a "layer SSL protocol over this socket" API.

- Dave

> One solution of course is to have a constructor in SSLSocketFactory
> which takes a java.net.Socket. However, this might not be such a nice
> solution. A possibly nicer one would be to be able to delay the SSL
> handshake on an SSLSocket. Example:
>
> SSLSocket sock = factory.getSocket("www.some.host", 443);
> sock.setAutomaticHandshake(false);
> ... // getInputStream()/getOutputStream() don't trigger
> // the handshake - all data read and written goes over
> // the connection as plaintext
> sock.startHandshake();
> ... // read()'s/write()'s to the streams are now SSL'd (i.e.
> // usually encrypted)
>
> This would require two new methods to SSLSocket: setAutomaticHandshake()
> and getAutomaticHandshake() (maybe a there is a better name...), with
> the default being the current behaviour (i.e. getInputStream() or
> getOutputStream() triggers startHandshake()).
>
> Pardon if this has been asked before, but I couldn't find any note to
> that effect.
>
> Cheers,
>
> Ronald

- Next message: Jan Luehe: "Re: Bug report"
- Previous message: Jan Luehe: "Re: Using signed applets with java plugin - clarification"
- Maybe in reply to: Life is hard, and then you die.: "http://java.sun.com/security/ssl/API_users_guide.html"