3

I have researched for a while now, and didn't see my exact same problem anywhere. I'm just having a specific, quite simple problem: whenever my echo_server tries to run SSL_accept() function, it won't block the server waiting for a client to connect, function will just return 0, and if I go into SSL_get_error(), it will give me SSL_ERROR_SYSCALL, so I'm guessing the problem is, quoting from the manual, "an EOF was observed that violates the protocol."

Truth is I have no idea what does that mean, and it's getting really frustrating because I think I'm missing something very simple, but I don't know what.

Here's the code for my accept function (SSL_ctx previously initialized and socket opened):

SSL * sslconnection;

if((sslconnection = SSL_new(ctx)) == NULL){
    return NULL;
}

if(SSL_set_fd(sslconnection, socketd) != 1){
    return NULL;
}

if(SSL_accept(sslconnection) != 1){
    return NULL;
}

return sslconnection;

Also, I've tried to check my certificates with "openssl verify -verbose -purpose sslserver -CAfile 'CACertificate' 'ServerCertificate'", but it would say my Server Certificate is ok.

Any help is welcome, thanks in advance. Hope it's something really stupid and I'm just so obfuscated I can't see it.

1 Answer 1

7

whenever my echo_server tries to run SSL_accept() function, it won't block the server waiting for a client to connect

SSL_accept does not call accept for you. It expects that accept has already been called.

The correct sequence of calls is:

  1. socket
  2. bind
  3. listen
  4. accept
  5. SSL_new
  6. SSL_set_fd
  7. SSL_accept

Download openssl sources from https://www.openssl.org/source/ and see demos/ssl/serv.cpp.

2
  • You save my life! How is it possible that, after calling accept() and the server is blocked, you can still do stuff like SSL_new(), etc.? Wouldn't it be blocked? Or that's the purpose? I mean, blocking it until a new connection is found and THEN executing the SSL part? Commented Jun 18, 2014 at 15:12
  • @DisplayName After accept returns you have a new client connection and the OS starts receiving data from the client (if any) in the background for you into the kernel socket buffer, that you will eventually read with read/recv/recvmsg. Commented Jun 18, 2014 at 15:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.