aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAnders Bakken <agbakken@gmail.com>2016-05-10 12:49:33 -0700
committerDaniel Stenberg <daniel@haxx.se>2016-05-11 00:06:40 +0200
commit856baf5a46e9d5fb71950a648ac6d1600838584d (patch)
treed9a12cd3f5f87de57590b9f2f28b3b5e7500d48e
parentf6767f5435f4c8230b382f18d4a2917ae37641d5 (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.c16
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