Why is OpenSSL causing a sigpipe @ SSL_connect?

Question

    int sfd = socket(AF_INET6, SOCK_STREAM, 0);
    if (sfd < 0) continue;
    struct timeval timeout;
    timeout.tv_sec = 60;
    timeout.tv_usec = 0;
    setsockopt(sfd, SOL_SOCKET, SO_RCVTIMEO, (char *) &timeout, sizeof(timeout));
    setsockopt(sfd, SOL_SOCKET, SO_SNDTIMEO, (char *) &timeout, sizeof(timeout));
    if (connect(sfd, (struct sockaddr*) &ig, sizeof(struct sockaddr_in6))) {
        close(sfd);
        continue;
    }
    SSL* ssl = SSL_new(ctx);
    if (ssl == NULL) {
        close(sfd);
        continue;
    }
    SSL_set_connect_state(ssl);
    SSL_set_fd(ssl, sfd);
    printf("%i\n", SSL_get_fd(ssl));
    int con = SSL_connect(ssl);

OpenSSL causes a SIGPIPE to be fired on the line that I call SSL_connect on. I ran through with GDB and ensured that the socket is not closed. In /proc/fd/#, the socket does not appear closed before or after. I tried switching the order of my set_fd and connect_state calls. I imagine I messed something up with OpenSSL, but I cannot seem to figure it out.

In the C code I've written for doing something like your example, I have not needed the explicit call to `SSL_set_connect_state(ssl)`; why are you using it? What happens if you remove it? — Castaglia, Apr 04 '16 at 17:17
I guess the next thing to try is to install a dummy/stub SIGPIPE signal handler. And to verify the logs/info on the server side of things, to see if it's rejecting anything. — Castaglia, Apr 04 '16 at 17:24

score 1 · Answer 1 · answered Apr 04 '16 at 20:46

SIGPIPE is triggered by the kernel if the application writes to a socket where the remote end of the connection was closed. Note that in this case the local file descriptor is still valid, but a write to it will result in SIGPIPE or EPIPE to signal that the data cannot be delivered to the remote end.

Since SSL_connect is doing a SSL handshake which consists of several data exchanges. My guess is that the server or some middlebox in between (like a firewall) closed the connection before the handshake was finished. The exact details of this behavior might be found out with a packet capture (i.e. wireshark or similar).

Why is OpenSSL causing a sigpipe @ SSL_connect?

1 Answers1