Re: possible SSL_write bug
You are right, it is just a signal I should ignore. Now it works perfectly. Maybe the fact that the SSL_write might rise a SIGPIPE should be in the documentation, because it happens only in particular situations (2 writes in a row with connection closed remotely), and it might cause occasional crashes of an application, which are harder to solve. Thanks for your help. David Schwartz ha scritto: Program received signal SIGPIPE, Broken pipe. You need to either catch or ignore SIGPIPE. There is also the output of the program. I think the focus should not be on the call the caused the crash, but on the call before, which returned 7 even if the connection was closed. There's nothing unusual about that. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: possible SSL_write bug
Alessandro Pivi - GLOBALcom engineering wrote: You are right, it is just a signal I should ignore. Now it works perfectly. Maybe the fact that the SSL_write might rise a SIGPIPE should be in the documentation, because it happens only in particular situations (2 writes in a row with connection closed remotely), and it might cause occasional crashes of an application, which are harder to solve. Thanks for your help. I guess it's implicit in the sense that /if/ the underlying BIO uses a socket then the scenario you described (writing into a broken connection) can generate a SIGPIPE. I wouldn't call it SSL_write()'s property. -jb -- I used to think I was indecisive, but now I'm not so sure. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: possible SSL_write bug
Sorry for my bad english, it crashes, it doesn't hang. It is not true I don't handle errors. The SSL_write always returns a positive value (the number of bytes I'm trying to write), which means there has not been an error. The SSL_get_error called with a positive value always returns SSL_ERROR_NONE. The SSL_read instead returns 0, and the SSL_get_error tells me it is a SSL_ERROR_SYSCALL, which is what I expected even by SSL_write. If the SSL_write recognized the error, the application would close properly (as it does with the dummy read). David Schwartz ha scritto: I found out that if I keep calling SSL_write, if the connection is closed remotely (killing stunnel), my application hangs. I thought your problem was crashing. Now I see that it's hanging. These are two totally different problems. I made some tests, and saw that the error happens only if I keep calling SSL_write. The first SSL_write after closing the connection returns a positive value, as if the closing wasn't seen. The second causes the hanging. Your read handler doesn't handle SSL_WANT_WRITE. Your write handler doesn't handle any of the SSL_WANT errors. It doesn't surprise me that your code spins in non-blocking mode. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: possible SSL_write bug
Sorry for my bad english, it crashes, it doesn't hang. Then compile with '-g' and run 'gdb' on the core dump. Post the output of the 'where' command. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: possible SSL_write bug
This is what you requested: (gdb) run Starting program: /home/develop/test/bin/sslTest h:127.0.0.1 port:16001 SSL Connection opened start op w: 7 start op w: 7 start op w: 7 start op w: 7 start op w: 7 start op w: 7 start op Program received signal SIGPIPE, Broken pipe. 0x4011f41e in write () from /lib/tls/libc.so.6 (gdb) where #0 0x4011f41e in write () from /lib/tls/libc.so.6 #1 0x4022bcd6 in BIO_CONNECT_free () from /usr/lib/i686/cmov/libcrypto.so.0.9.8 #2 0x40228dd3 in BIO_write () from /usr/lib/i686/cmov/libcrypto.so.0.9.8 #3 0x4003de8e in ssl3_write_pending () from /usr/lib/i686/cmov/libssl.so.0.9.8 #4 0x4003e1a7 in ssl3_do_compress () from /usr/lib/i686/cmov/libssl.so.0.9.8 #5 0x4003e4bf in ssl3_write_bytes () from /usr/lib/i686/cmov/libssl.so.0.9.8 #6 0x4003b892 in ssl3_write () from /usr/lib/i686/cmov/libssl.so.0.9.8 #7 0x4004bfc9 in SSL_write () from /usr/lib/i686/cmov/libssl.so.0.9.8 #8 0x08048bb7 in writeSocketSSL (msg=0x8049319 "hello\r\n", len=37) at sslTest.c:268 #9 0x08048f62 in main () at sslTest.c:308 There is also the output of the program. I think the focus should not be on the call the caused the crash, but on the call before, which returned 7 even if the connection was closed. David Schwartz ha scritto: Sorry for my bad english, it crashes, it doesn't hang. Then compile with '-g' and run 'gdb' on the core dump. Post the output of the 'where' command. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: possible SSL_write bug
Program received signal SIGPIPE, Broken pipe. You need to either catch or ignore SIGPIPE. There is also the output of the program. I think the focus should not be on the call the caused the crash, but on the call before, which returned 7 even if the connection was closed. There's nothing unusual about that. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: possible SSL_write bug
I found out that if I keep calling SSL_write, if the connection is closed remotely (killing stunnel), my application hangs. I thought your problem was crashing. Now I see that it's hanging. These are two totally different problems. I made some tests, and saw that the error happens only if I keep calling SSL_write. The first SSL_write after closing the connection returns a positive value, as if the closing wasn't seen. The second causes the hanging. Your read handler doesn't handle SSL_WANT_WRITE. Your write handler doesn't handle any of the SSL_WANT errors. It doesn't surprise me that your code spins in non-blocking mode. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: possible SSL_write bug
Hi,
I found out that if I keep calling SSL_write, if the connection is
closed remotely (killing stunnel), my application hangs. I made some
tests, and saw that the error happens only if I keep calling SSL_write.
The first SSL_write after closing the connection returns a positive
value, as if the closing wasn't seen. The second causes the hanging. If
I call SSL_read and SSL_write, the first SSL_read after closing the
connection remotely returns an error code, so I can notice what
happened and close the connection even in the application.
This is my sample code, you can comment and decomment #define BUG_FIX
to switch between the two behaviors. In my example I use a dummy 0 byte
read to prevent the hanging. I removed certificate verification and
private key loading here to make the application more readable, but the
behavior was exactly the same with these operations.
//
//test ssl
//
#include stdio.h
#include unistd.h
#include stdlib.h
#include pthread.h
#include termios.h
#include unistd.h
#include sys/ioctl.h
#include sys/types.h
#include sys/signal.h
#include sys/socket.h
#include string.h
#include fcntl.h
#include signal.h
#include errno.h
#include netdb.h
#include netinet/in.h
#include ctype.h
#include openssl/bio.h
#include openssl/err.h
#include openssl/rand.h
#include openssl/ssl.h
#include openssl/x509v3.h
//
#define int_error(msg) {fprintf(stderr, "** %s:%i %s\n", __FILE__,
__LINE__, msg); exit(0);}
//
#define CIPHER_LIST "ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH"
#define HOST "127.0.0.1"
#define PORT 16001
#define NON_BLOCKING
#define BUG_FIX
//
BIO * conn = NULL;
SSL * ssl = NULL;
SSL_CTX * ctx = NULL;
static int check_err(SSL *ssl, int ret)
{
int r =SSL_get_error(ssl, ret);
switch(r)
{
case SSL_ERROR_NONE:
fprintf(stderr, "SSL_ERROR_NONE\n");
break;
case SSL_ERROR_ZERO_RETURN:
fprintf(stderr, "SSL_ERROR_ZERO_RETURN\n");
break;
case SSL_ERROR_WANT_READ:
fprintf(stderr,"SSL_ERROR_WANT_READ\n");
break;
case SSL_ERROR_WANT_WRITE:
fprintf(stderr, "SSL_ERROR_WANT_WRITE\n");
break;
case SSL_ERROR_WANT_CONNECT:
fprintf(stderr,"SSL_ERROR_WANT_CONNECT\n");
break;
case SSL_ERROR_WANT_ACCEPT:
fprintf(stderr, "SSL_ERROR_WANT_ACCEPT\n");
break;
case SSL_ERROR_WANT_X509_LOOKUP:
fprintf(stderr, "SSL_ERROR_WANT_X509_LOOKUP\n");
break;
case SSL_ERROR_SYSCALL:
fprintf(stderr, "SSL_ERROR_SYSCALL\n");
break;
case SSL_ERROR_SSL:
fprintf(stderr, "SSL_ERROR_SSL\n");
break;
default:
fprintf(stderr, "SSL_???\n");
break;
}
return r;
}
static SSL_CTX *setup_client_ctx()
{
SSL_CTX *ctx;
ctx = SSL_CTX_new(SSLv23_method());
if(ctx == NULL)
return NULL;
SSL_CTX_set_options(ctx, SSL_OP_ALL|SSL_OP_NO_SSLv2);
if (SSL_CTX_set_cipher_list(ctx, CIPHER_LIST) != 1)
{
int_error("Error setting cipher list (no valid ciphers)");
SSL_CTX_free(ctx);
return NULL;
}
return ctx;
}
int closeSocketSSL()
{
if(ssl != NULL)
{
SSL_shutdown(ssl);
SSL_free(ssl);
ssl = NULL;
}
if(ctx != NULL)
{
SSL_CTX_free(ctx);
ctx = NULL;
}
if(conn != NULL)
{
conn = NULL;
}
return 0;
}
int openSocketSSL(const char * host, unsigned short port)
{
int ret;
long err;
if (!SSL_library_init())
{
fprintf(stderr, "** OpenSSL initialization failed!");
return -1;
}
RAND_load_file("/dev/urandom", 1024);
conn = NULL;
ssl = NULL;
ctx = NULL;
ctx = setup_client_ctx();
if(ctx == NULL)
{
closeSocketSSL();
return -1;
}
{
char buff[512];
sprintf(buff, "%s:%d", (host != NULL) ? host : "127.0.0.1" ,
port);
printf(buff);
conn = BIO_new_connect(buff/*SERVER ":" PORT*/);
}
if (!conn)
{
int_error("Error creating connection BIO");
closeSocketSSL();
return -1;
}
#ifdef NON_BLOCKING
if(BIO_set_nbio(conn,1)!= 1)
{
int_error("Error setting non-blocking IO");
closeSocketSSL();
return -1;
}
#endif
while((err=BIO_do_connect(conn)) = 0)
{
if(!BIO_should_retry(conn))
{
int_error("Error connecting to remote machine");
RE: possible SSL_write bug
If I close stunnel, the next SSL_write will return a positive value, as if everything is ok, the second causes sudden application termination. Make a build with debugging symbols, get a core dump, and analyze it with 'gdb' or similar. Alternatively, post the smallest complete, compilable example of code that demonstrates the problem. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: possible SSL_write bug
Hi, I made more tests, I even adapted sample code from samples I got in the web, and I always have the same result. If I close stunnel, the next SSL_write will return a positive value, as if everything is ok, the second causes sudden application termination. Could anybody please verify this behavior? It is possible that this is just my mistake, but I think it is worth looking because I might have found a big bug. Thanks in advance. David Schwartz ha scritto: I made a program that connects to a stunnel server. I am able to connect to the server, read, write, with no problems. Good. The problem is that if I close the stunnel, I can handle the error correctly if I make an SSL_read, but not if I make an SSL_write. The SSL_write returns a positive value even if the stunnel is closed, and on next SSL_write the application closes suddently. The first part is typical. Depending on exactly how the tunnel was closed, a write may not detect it immediately. As for your application closing suddenly on the next SSL_write, this is abnormal. Most likely, it's a bug in your program. It could be a bad OpenSSL build or a bug in OpenSSL, but that's unlikely. So if I close the stunnel, and make two writes in a row in my application, my application dies. Figure out why. Get a core dump or attach a debugger and see why and where it's dying. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
possible SSL_write bug
Hi, I made a program that connects to a stunnel server. I am able to connect to the server, read, write, with no problems. The problem is that if I close the stunnel, I can handle the error correctly if I make an SSL_read, but not if I make an SSL_write. The SSL_write returns a positive value even if the stunnel is closed, and on next SSL_write the application closes suddently. So if I close the stunnel, and make two writes in a row in my application, my application dies. Is there a function I should call before the SSL_write to check the status of the connection? Thanks in advance. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: possible SSL_write bug
I made a program that connects to a stunnel server. I am able to connect to the server, read, write, with no problems. Good. The problem is that if I close the stunnel, I can handle the error correctly if I make an SSL_read, but not if I make an SSL_write. The SSL_write returns a positive value even if the stunnel is closed, and on next SSL_write the application closes suddently. The first part is typical. Depending on exactly how the tunnel was closed, a write may not detect it immediately. As for your application closing suddenly on the next SSL_write, this is abnormal. Most likely, it's a bug in your program. It could be a bad OpenSSL build or a bug in OpenSSL, but that's unlikely. So if I close the stunnel, and make two writes in a row in my application, my application dies. Figure out why. Get a core dump or attach a debugger and see why and where it's dying. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
