diff options
author | Anders Bakken <agbakken@gmail.com> | 2016-05-10 12:49:33 -0700 |
---|---|---|
committer | Daniel Stenberg <daniel@haxx.se> | 2016-05-11 00:06:40 +0200 |
commit | 856baf5a46e9d5fb71950a648ac6d1600838584d (patch) | |
tree | d9a12cd3f5f87de57590b9f2f28b3b5e7500d48e | |
parent | f6767f5435f4c8230b382f18d4a2917ae37641d5 (diff) |
TLS: SSL_peek is not a const operation
Calling SSL_peek can cause bytes to be read from the raw socket which in
turn can upset the select machinery that determines whether there's data
available on the socket.
Since Curl_ossl_check_cxn only tries to determine whether the socket is
alive and doesn't actually need to see the bytes SSL_peek seems like
the wrong function to call.
We're able to occasionally reproduce a connect timeout due to this
bug. What happens is that Curl doesn't know to call SSL_connect again
after the peek happens since data is buffered in the SSL buffer and thus
select won't fire for this socket.
Closes #795
-rw-r--r-- | lib/vtls/openssl.c | 16 |
1 files changed, 8 insertions, 8 deletions
diff --git a/lib/vtls/openssl.c b/lib/vtls/openssl.c index 823dcebbc..7f7406544 100644 --- a/lib/vtls/openssl.c +++ b/lib/vtls/openssl.c @@ -759,17 +759,17 @@ void Curl_ossl_cleanup(void) */ int Curl_ossl_check_cxn(struct connectdata *conn) { - int rc; +#ifdef MSG_PEEK char buf; - - rc = SSL_peek(conn->ssl[FIRSTSOCKET].handle, (void*)&buf, 1); - if(rc > 0) - return 1; /* connection still in place */ - - if(rc == 0) + if(recv((RECV_TYPE_ARG1)conn->sock[FIRSTSOCKET], (RECV_TYPE_ARG2)&buf, + (RECV_TYPE_ARG3)1, (RECV_TYPE_ARG4)MSG_PEEK) == 0) { return 0; /* connection has been closed */ - + } + else + return 1; /* connection still in place */ +#else return -1; /* connection status unknown */ +#endif } /* Selects an OpenSSL crypto engine |