<div dir="ltr">Hello,<br><br>I have developed a client-server application with openssl and I have a recurrent bug where, sometimes, server instance seems to be definitively stuck in SSL_read call.<br><br>I have put more details of the problem here below, but it seems that in some rare execution cases, the server performs a SSL_read, the client disconnects in the meantime, and the server never detects the disconnection and remains stuck in the SSL_read operation.<br><br>My server runs on a Debian 6.3, and my version of openssl is 1.1.0l.<br><br>Here is an extract of the code that manages the SSL connexion at server side : <br><br>   ctx = SSL_CTX_new(SSLv23_server_method());<br><br>   BIO* bio = BIO_new_file("dhkey.pem", "r");<br>   if (bio == NULL) ...<br>   DH* ret = PEM_read_bio_DHparams(bio, NULL, NULL, NULL);<br>   BIO_free(bio);<br>   if (SSL_CTX_set_tmp_dh(ctx, ret) < 0) ...<br><br>   SSL_CTX_set_default_passwd_cb_userdata(ctx, (void*)key);<br>   if (SSL_CTX_use_PrivateKey_file(ctx, "server.key", SSL_FILETYPE_PEM) <= 0) ...<br>   if (SSL_CTX_use_certificate_file(ctx, "server.crt", SSL_FILETYPE_PEM) <= 0) ...<br>   if (SSL_CTX_check_private_key(ctx) == 0) ...<br>   SSL_CTX_set_cipher_list(ctx, "ALL");<br><br>   ssl_in = SSL_new(ctx);<br>   BIO* sslclient_in = BIO_new_socket(in_sock, BIO_NOCLOSE);<br>   SSL_set_bio(ssl_in, sslclient_in, sslclient_in);<br>   int r_in = SSL_accept(ssl_in);<br>   if (r_in != 1) ...<br>   <br>   ...<br>   <br>   /* Place where program hangs : */<br>   int read = SSL_read(ssl_in, &(((char*)ptr)[nb_read]), size-nb_read);<br>   <br>Here is the full stack-trace where the program hangs : <br><br>#0  0x00007f836575d210 in __read_nocancel () from /lib/x86_64-linux-gnu/libpthread.so.0<br>#1  0x00007f8365c8ccec in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1<br>#2  0x00007f8365c8772b in BIO_read () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1<br>#3  0x00007f83659879a2 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1<br>#4  0x00007f836598b70d in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1<br>#5  0x00007f8365989113 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1<br>#6  0x00007f836598eff6 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1<br>#7  0x00007f8365998dc9 in SSL_read () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1<br>#8  0x000055b7b3e98289 in Socket::SslRead (this=0x7ffdc6131900, size=4, ptr=0x7ffdc613066c)<br>    at ../../Utilities/Database/Sync/server/Communication/Socket.cpp:80<br><br>Here is the result of "netstat -natp | grep <pid of hanging process>" : <br><br>tcp       32      0 <a href="http://5.196.111.132:5412">5.196.111.132:5412</a>      <a href="http://109.133.193.70:51822">109.133.193.70:51822</a>    CLOSE_WAIT  19218/./MabeeServer<br>tcp       32      0 <a href="http://5.196.111.132:5412">5.196.111.132:5412</a>      <a href="http://109.133.193.70:51696">109.133.193.70:51696</a>    CLOSE_WAIT  19218/./MabeeServer<br>tcp       32      0 <a href="http://5.196.111.132:5412">5.196.111.132:5412</a>      <a href="http://109.133.193.70:51658">109.133.193.70:51658</a>    CLOSE_WAIT  19218/./MabeeServer<br>tcp        0      0 <a href="http://5.196.111.132:5413">5.196.111.132:5413</a>      <a href="http://85.27.92.8:25856">85.27.92.8:25856</a>        ESTABLISHED 19218/./MabeeServer<br>tcp       32      0 <a href="http://5.196.111.132:5412">5.196.111.132:5412</a>      <a href="http://109.133.193.70:51818">109.133.193.70:51818</a>    CLOSE_WAIT  19218/./MabeeServer<br>tcp       32      0 <a href="http://5.196.111.132:5412">5.196.111.132:5412</a>      <a href="http://109.133.193.70:51740">109.133.193.70:51740</a>    CLOSE_WAIT  19218/./MabeeServer<br>tcp        0      0 <a href="http://5.196.111.132:5412">5.196.111.132:5412</a>      <a href="http://85.27.92.8:26305">85.27.92.8:26305</a>        ESTABLISHED 19218/./MabeeServer<br>tcp6       0      0 ::1:36448               ::1:5432                ESTABLISHED 19218/./MabeeServer<br><br>From this log, I can see that I have two established connections with remote client machine on IP 109.133.193.70. Note that it's normal to have two connexions because my client-server protocol relies on two distinct TCP connexions.<br><br>From this, I logged the result of a "tcpdump -i any -nn host 85.27.92.8" during two days (and during those two days, my server instance remained stuck in SSL_read...). On this log, I see no packet exchange on ports <a href="http://85.27.92.8:25856">85.27.92.8:25856</a> or <a href="http://85.27.92.8:26305">85.27.92.8:26305</a>. I see some burst of packets exchanged on other client TCP ports, but probably due to the client that performs other requests to the server (and thus, the server that is forking new instances with connections on other client ports).<br><div><br></div><div>This let me think that the connexion on which the SSL_read is listening is definitively dead (no more TCP keepalive), and that, for a reason I do not understand, the SSL_read keeps blocked into it.</div><div><br></div><div>Note that the normal behavior of my application is : client connects, server daemon forks a new instance, communication remains a few seconds with forked server instance, client disconnects and the forked process finished.</div><div><br></div><div>Note also that normally, client performs a proper disconnection (SSL_shutdown, etc.). But I cannot guarantee it never interrupts on a more abrupt way (connection lost, client crash, etc.).<br></div><div><br></div>Any advice on what is going wrong ?<br><br>Many thanks,<br><br>Brice</div>