0

Here's some pseudocode

Client:
    boolean sent = false;
    byte[] message = new String("test").getBytes();

    send()
    {
        sent = sslSocket.sendMessage(message);

        if (sent)
            sslSocket.close();
    }

I'm writing tests that should be fairly quick. Once the Client successfully sends a message, it should close immediately. In my tests, the Client returns sent == true, so the socket closes. However, the Server is throwing a received close_notify during handshake exception. This exception does not happen when I use Thread.sleep(200) right before closing the Client.

Our sockets are our own abstractions and wrappers for Java's sockets. From this post, I have to assume that the Server has not completed the handshake, but the Client has? Why else would sent return true? I can't confirm that the message actually HAS been received by the Server, however, because the exception is thrown immediately. I only have Client sent boolean to rely on.

So my question is how can I confirm the handshake was completed?

Thank you for the help, and sorry for any ambiguity! I can clear any confusions!

  • 2
    What class is `sslSocket`? [SSLSocket](https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocket.html) does not appear to have a `sendMessage` method. The reason `sent` would be true is because `sendMessage` returns `true`, there's a reason why it returns that however I can't find it yet (since I'm not sure what `sslSocket` is). – Mark Dec 12 '18 at 17:42
  • It's our own method and abstracts Java Sockets. I'm fairly new to the code and can't really see what it does exactly. Ignoring the code, is it possible for a client to send a message to the server before a handshake is completed? I'm new to SSL too and don't entirely understand how that could work – thelostmachine Dec 12 '18 at 18:14

1 Answers1

1

@Mark brought up a good point about the sendMessage() method. I looked into it more, and it doesn't return true when the message has been sent, but returns when the message has been placed on an output queue. So it turns out the message probably was never actually sent. Documentation was incorrect.

Thus, the handshake was never actually complete and sent was a lie because the connection was never fully open.

Thank you @Mark!