Adding hostname verification to SSLSocket

[Ian Pilcher]

I am working with a library that can use an application-provided
SSLSocketFactory to create its SSL connections. I would like to ensure
that all of its connections enforce hostname verification, which the
default SSLSocket implementation does not do.

It's tempting to simply write an SSLSocketFactory that does the hostname
verification in its various createSocket(...) methods, but this
obviously won't cover the case where a socket is created in an
unconnected state with createSocket() and connected later. (It's also
not at all clear from the documentation that connect(...) can't be
called on a connected socket to connect it to a different server.)

So it seems that doing this the "right" way is going to require an
SSLSocket implementation -- something like this:

public final class HostVerifyingSSLSocketextends SSLSocket
{
private final SSLSocket socket;
private final HostnameVerifier verifier;

public HostVerifyingSSLSocket(SSLSocket socket,
HostnameVerifier verifier)
throws SSLHandshakeException
{
this.socket = socket;
this.verifier = verifier;
if (socket.isConnected()) {
verify();
}
}

private void verify() throws SSLHandshakeException
{
SSLSession session = socket.getSession();
if (!verifier.verify(session.getPeerHost(), session)) {
IOException closeException = null;
try {
socket.close();
} catch (IOException ioe) {
closeException = ioe;
}
SSLHandshakeException she =
new SSLHandshakeException("Bummer");
if (closeException != null) {
she.addSuppressed(closeException);
}
throw she;
}
}

// Delegate all Socket and SSLSocket methods to socket ...


The question is which of the delegated methods need a call to verify().
I'm thinking that connect(), startHandshake(), and getSession() are the
only methods that need this. (And getHandshakeSession() is right out.)

public void connect(SocketAddress endpoint) throws IOException
{
socket.connect(endpoint);
verify();
}

public void connect(SocketAddress endpoint, int timeout)
throws IOException
{
socket.connect(endpoint, timeout);
verify();
}

public void startHandshake() throws IOException
{
socket.startHandshake();
verify();
}

public SSLSession getSession()
{
try {
Session session = socket.getSession();
validate();
return session;
} catch (SSLHandshakeException she) {
return ERROR_SESSION; // Need to create this. Uugh.
}
}

public SSLSession getHandshakeSession()
{
throw new UnsupportedOperationException("Sorry");
}

Any others? Anyone see any fundamental problem with this approach
(other than the fact that it's a ton of mostly boilerplate code to work
around the fact that HandshakeCompletedListener.handShakeCompleted(...)
isn't allowed to throw a checked exception)?

Thanks!

 

[Roedy Green]

I would like to ensure
that all of its connections enforce hostname verification, which the
default SSLSocket implementation does not do.

Are you sure about that? IIRC I had the opposite problem link
checking with links with a mismatch considered bad. Mis-matches are
extremely common, particularly for large companies with many servers.

 

[Arne Vajhøj]

I am working with a library that can use an application-provided
SSLSocketFactory to create its SSL connections. I would like to ensure
that all of its connections enforce hostname verification, which the
default SSLSocket implementation does not do.

It's tempting to simply write an SSLSocketFactory that does the hostname
verification in its various createSocket(...) methods, but this
obviously won't cover the case where a socket is created in an
unconnected state with createSocket() and connected later. (It's also
not at all clear from the documentation that connect(...) can't be
called on a connected socket to connect it to a different server.)

So it seems that doing this the "right" way is going to require an
SSLSocket implementation -- something like this:

Any others? Anyone see any fundamental problem with this approach
(other than the fact that it's a ton of mostly boilerplate code to work
around the fact that HandshakeCompletedListener.handShakeCompleted(...)
isn't allowed to throw a checked exception)?

If you are using SSL for HTTPS, then I think that
HttpsURLConnection.setDefaultHostnameVerifier would be obvious. But
I assume that is not the case.

Arne