How do I know if a server supports SSL?

Question

I need to connect to a host, if it's off-line I get a TCP timeout (and it's ok), and if it's online with SSL available, I proceed to the logon phase.

The problem is, when the server is online, accepts connection on the configured TCP port, but then doesn't answer to SSL handshake, our application waits indefinitely for an answer.

I'm using IBM HACL (c++) wrapped by JNI to access the server.

How could I test (in Java or C++ under Windows XP) the availability of SSL on the server side? Can I start a handshake manually, get the first server response, and then close the TCP socket? Or do I need to complete the handshake (and how do I?)

Thanks.

Answer 1

In SSL, the first message to be sent is always by the client: a ClientHello. The server should response with a ServerHello message, so that'll be when you know it supports SSL. You can close the connection (by sending a close_notify alert) at any point. You do not need to complete the handshake.

Iit is quite common for peers to terminate mid-handshake if the session parameters do not allow a trusted session be established.

In Java, the SSLEngine class gives you the sort of control you desire over the SSL handshake, but it is quite a complex state machine requiring in-depth knowledge of SSL.

Answer 2

try {
    SSLContext ctx = SSLContext.getDefault();
    ctx.getClientSessionContext().setSessionTimeout(5); // in seconds
    SSLSocket socket = (SSLSocket) 
         ctx.getSocketFactory().createSocket("host.com", 443);

    socket.setSoTimeout(5000); // in millis
    socket.startHandshake();
} catch (IOException ex) {
    sslAvailable = false;
}

As per your comment the socket.setSoTimeout(5000) did the trick.

If that doesn't work, then:

URLConnection urlConn = // obtain connection
urlConn.setConnectTimeout(5000); // in millis

Answer 3

The problem is, when the server is online, accepts connection on the configured TCP port, but then doesn't answer to SSL handshake, our application waits indefinitely for an answer.

As general purpose solution why not put the connect code into a thread and waiting for the thread until a timeout is reached.