Subclassing SSLSocket

[Robert]

Hi all,

I'd like to specialize a SSLSocket with the following functionality:
- after the 'normal' SSL Handshake phase, do some more stuff (as part
of an 'extended' handshake)

While trying to achieve this, I've stumbled upon the problem that the
javax.net.ssl.SSLSocket class is merely a proxy for a SocketImpl (e.g.
com.sun.net.ssl.internal.ssl.SSLSocketImpl).

The main thing I'm wondering right now is whether I really need to
subclass an Implementing class to achieve what I want to achieve? And
if so, where do I find any documentation on such an implementing
class? It seems the Java API docs only provide documentation for the
"proxy" classes...

I hope you can help me!

Best regards,
Robert

 

[Oliver Wong]

Hi all,

I'd like to specialize a SSLSocket with the following functionality:
- after the 'normal' SSL Handshake phase, do some more stuff (as part
of an 'extended' handshake)

While trying to achieve this, I've stumbled upon the problem that the
javax.net.ssl.SSLSocket class is merely a proxy for a SocketImpl (e.g.
com.sun.net.ssl.internal.ssl.SSLSocketImpl).

The main thing I'm wondering right now is whether I really need to
subclass an Implementing class to achieve what I want to achieve? And
if so, where do I find any documentation on such an implementing
class? It seems the Java API docs only provide documentation for the
"proxy" classes...

I hope you can help me!

Maybe something like:

<pseudocode>
public class MySSLSocket extends SSLSocket{
private final SSLSocket internalSocket;

public MySSLSocket(SSLSocket ssls) {
this.internalSocket = ssls;
}

@Override
public void startHandshake() {
this.internalSocket.startHandshake();
doExtendedHandshake();
}

private void doExtendedHandshake() {
/*Do something here*/
}
}
</pseudocode>

Basically, your class acts as a wrapper around another class which
does most of the work, and you just add your extra handshaking stuff at
the appropriate place.

- Oliver

 

[Esmond Pitt]

Hi all,

I'd like to specialize a SSLSocket with the following functionality:
- after the 'normal' SSL Handshake phase, do some more stuff (as part
of an 'extended' handshake)

Don't bother with subclassing, it's too hard. Just add a
HandshakeCompletionListener and do what you have to do in there.

 

[Robert]

Thank you for your answers!

I realize that I should delegate instead of subclassing, and indeed,
implementing a HandshakeCompletionListener would suffice.
However, this still gives me a problematic situation:

I am not actually creating SSLSocketFactory / SSLSocket objects
myself, but I would like to hook my own factories / sockets into the
JSSE system, and I'm trying to do this using the
"ssl.SocketFactory.provider" security property. My socketfactory would
simply delegate its tasks to the default socketfactory, but add a
HandshakeCompletionListener to the created socket before returning it.

Now, I believe this is not possible since:
1. The "default" SSLSocketFactory implementation can be accessed
through the ssl.SocketFactory.provider property
2. If I override the ssl.SocketFactory.provider property, how do I
create a SSLSocketFactory within my custom Factory?

First retrieving the default SSLSocketFactory by calling
SSLSocketFactory.getDefault() and then creating my custom class does
not work: after the default socketfactory has been created, changing
the ssl.SocketFactory.provider property has no effect.


How can I solve this?

Thanks,
Robert

 

[Esmond Pitt]

How can I solve this?

Save the old value of the provider property before you change it. You
can then get the default SSLContext via that provider via
SSLContext.getInstance(String protocol, Provider provider), at any time.