OpenSSL › OpenSSL - User

SSL_shutdown and SIGPIPE

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

16 messages Options

Alberto Alonso

SSL_shutdown and SIGPIPE

I am getting SIGPIPE signals under Linux when calling
on SSL_shutdown and the remote is gone.

Basically, the remote end terminates the connection abruptly,
then the server finishes doing whatever is doing and issues
a SSL_shutdown on the ssl structure that used to handle the
connection. This generates a SIGPIPE on the server.

Is there anything I should be checking for before calling
SSL_shutdown to make sure the connection is still OK?

Thanks,

Alberto
--
Alberto Alonso Global Gate Systems LLC.
(512) 351-7233 http://www.ggsys.net
Hardware, consulting, sysadmin, monitoring and remote backups

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [hidden email]
Automated List Manager [hidden email]

Girish Venkatachalam

Re: SSL_shutdown and SIGPIPE

The standard practice is that of ignoring SIGPIPE in
all TCP servers.

signal(SIGPIPE,SIG_IGN);

OpenSSL cannot help you here because the problem
occurs at a lower level(TCP).

I remember seeing this line in the ssh server source
code as well.

regards,
Girish

--- Alberto Alonso <[hidden email]> wrote:

> I am getting SIGPIPE signals under Linux when
> calling
> on SSL_shutdown and the remote is gone.
>
> Basically, the remote end terminates the connection
> abruptly,
> then the server finishes doing whatever is doing and
> issues
> a SSL_shutdown on the ssl structure that used to
> handle the
> connection. This generates a SIGPIPE on the server.
>
> Is there anything I should be checking for before
> calling
> SSL_shutdown to make sure the connection is still
> OK?
>
>
> Thanks,
>
> Alberto
> --
> Alberto Alonso Global Gate
> Systems LLC.
> (512) 351-7233
> http://www.ggsys.net
> Hardware, consulting, sysadmin, monitoring and
> remote backups
>
>

______________________________________________________________________
> OpenSSL Project
> http://www.openssl.org
> User Support Mailing List
> [hidden email]
> Automated List Manager
> [hidden email]
>

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [hidden email]
Automated List Manager [hidden email]

Gayathri Sundar-2

RE: SSL_shutdown and SIGPIPE

In reply to this post by Alberto Alonso

Probably you can call the following

iRet = SSL_get_shutdown(pSSL);
if(iRet >= 0) SSL_shutdown(pSSL);

This is because, SSL_shutdown writes data on the wire,
i.e the closure alerts..and if a FIN was received meanwhile,
you will catch a SIGPIPE..this piece of code, actually
saves me from this..

Thanks
--G3

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]]On Behalf Of Alberto Alonso
Sent: Sunday, February 12, 2006 2:08 PM
To: [hidden email]
Subject: SSL_shutdown and SIGPIPE

I am getting SIGPIPE signals under Linux when calling
on SSL_shutdown and the remote is gone.

Basically, the remote end terminates the connection abruptly,
then the server finishes doing whatever is doing and issues
a SSL_shutdown on the ssl structure that used to handle the
connection. This generates a SIGPIPE on the server.

Is there anything I should be checking for before calling
SSL_shutdown to make sure the connection is still OK?

Thanks,

Alberto
--
Alberto Alonso Global Gate Systems LLC.
(512) 351-7233 http://www.ggsys.net
Hardware, consulting, sysadmin, monitoring and remote backups

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [hidden email]
Automated List Manager [hidden email]

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [hidden email]
Automated List Manager [hidden email]

Kyle Hamilton

Re: SSL_shutdown and SIGPIPE

Why are you trying to avoid SIGPIPE, anyway? It's easy to ignore, and
a global state would make it possible to determine what socket you
were writing on (if you needed that).

-Kyle H

On 2/12/06, Gayathri Sundar <[hidden email]> wrote:

> Probably you can call the following
>
> iRet = SSL_get_shutdown(pSSL);
> if(iRet >= 0) SSL_shutdown(pSSL);
>
> This is because, SSL_shutdown writes data on the wire,
> i.e the closure alerts..and if a FIN was received meanwhile,
> you will catch a SIGPIPE..this piece of code, actually
> saves me from this..
>
> Thanks
> --G3
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of Alberto Alonso
> Sent: Sunday, February 12, 2006 2:08 PM
> To: [hidden email]
> Subject: SSL_shutdown and SIGPIPE
>
>
> I am getting SIGPIPE signals under Linux when calling
> on SSL_shutdown and the remote is gone.
>
> Basically, the remote end terminates the connection abruptly,
> then the server finishes doing whatever is doing and issues
> a SSL_shutdown on the ssl structure that used to handle the
> connection. This generates a SIGPIPE on the server.
>
> Is there anything I should be checking for before calling
> SSL_shutdown to make sure the connection is still OK?
>
>
> Thanks,
>
> Alberto
> --
> Alberto Alonso Global Gate Systems LLC.
> (512) 351-7233 http://www.ggsys.net
> Hardware, consulting, sysadmin, monitoring and remote backups
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List [hidden email]
> Automated List Manager [hidden email]
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List [hidden email]
> Automated List Manager [hidden email]
>

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [hidden email]
Automated List Manager [hidden email]

Alberto Alonso

RE: SSL_shutdown and SIGPIPE

In reply to this post by Gayathri Sundar-2

Excellent, I'll give this a try.

Thanks,

Alberto

On Mon, 2006-02-13 at 10:51 +0530, Gayathri Sundar wrote:

--
Alberto Alonso Global Gate Systems LLC.
(512) 351-7233 http://www.ggsys.net
Hardware, consulting, sysadmin, monitoring and remote backups

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [hidden email]
Automated List Manager [hidden email]

Alberto Alonso

Re: SSL_shutdown and SIGPIPE

In reply to this post by Kyle Hamilton

I personally don't know why pipes are even in use in the openssl
internals (though I bet there is a good reason for it :-)

Ignoring SIGPIPE (or most signals for that matter) is not really
that good. They get generated for good reasons.

In my case, depending on what came down the wire, I have to interact
with other utilities in the system, therefore opening pipes. I need
to make sure I get the signals when a system tool exits unexpectedly.

Alberto

On Sun, 2006-02-12 at 22:45 -0700, Kyle Hamilton wrote:

> Why are you trying to avoid SIGPIPE, anyway? It's easy to ignore, and
> a global state would make it possible to determine what socket you
> were writing on (if you needed that).
>
> -Kyle H
>
> On 2/12/06, Gayathri Sundar <[hidden email]> wrote:
> > Probably you can call the following
> >
> > iRet = SSL_get_shutdown(pSSL);
> > if(iRet >= 0) SSL_shutdown(pSSL);
> >
> > This is because, SSL_shutdown writes data on the wire,
> > i.e the closure alerts..and if a FIN was received meanwhile,
> > you will catch a SIGPIPE..this piece of code, actually
> > saves me from this..
> >
> > Thanks
> > --G3
> >
> > -----Original Message-----
> > From: [hidden email]
> > [mailto:[hidden email]]On Behalf Of Alberto Alonso
> > Sent: Sunday, February 12, 2006 2:08 PM
> > To: [hidden email]
> > Subject: SSL_shutdown and SIGPIPE
> >
> >
> > I am getting SIGPIPE signals under Linux when calling
> > on SSL_shutdown and the remote is gone.
> >
> > Basically, the remote end terminates the connection abruptly,
> > then the server finishes doing whatever is doing and issues
> > a SSL_shutdown on the ssl structure that used to handle the
> > connection. This generates a SIGPIPE on the server.
> >
> > Is there anything I should be checking for before calling
> > SSL_shutdown to make sure the connection is still OK?
> >
> >
> > Thanks,
> >
> > Alberto
> > --
> > Alberto Alonso Global Gate Systems LLC.
> > (512) 351-7233 http://www.ggsys.net
> > Hardware, consulting, sysadmin, monitoring and remote backups
> >
> > ______________________________________________________________________
> > OpenSSL Project http://www.openssl.org
> > User Support Mailing List [hidden email]
> > Automated List Manager [hidden email]
> >
> > ______________________________________________________________________

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [hidden email]
Automated List Manager [hidden email]

Goetz Babin-Ebell

Re: SSL_shutdown and SIGPIPE

Hallo Alberto,
Alberto Alonso schrieb:
> I personally don't know why pipes are even in use in the openssl
> internals (though I bet there is a good reason for it :-)

OpenSSL doesn't use pipes.
You get a SIGPIPE if you write to a socket for that
the other end is closed.

I prefer using send() with MSG_NOSIGNAL,
but that is not supported on every platform OpenSSL runs on...

> Ignoring SIGPIPE (or most signals for that matter) is not really
> that good. They get generated for good reasons.
>
> In my case, depending on what came down the wire, I have to interact
> with other utilities in the system, therefore opening pipes. I need
> to make sure I get the signals when a system tool exits unexpectedly.

SIGPIPE is something you normally can ignore:

if the write fails, you get an error return value
and can check errno for EPIPE.

This has the advantage you handle the closed connection
on the function that fails and not in an global signal handler...

Bye

Goetz

--
DMCA: The greed of the few outweighs the freedom of the many

smime.p7s (4K) Download Attachment

Gayathri Sundar-2

RE: SSL_shutdown and SIGPIPE

In reply to this post by Kyle Hamilton

yeah, I have an unusual requirement dat, I cant ignore sigpipe..
meanwhile, SSL_get_shutdown will check the FD status, and if a FIN/RST
was received, the return value will reflect dat..so I will not
even attempt a write.

Thanks
--G3

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]]On Behalf Of Kyle Hamilton
Sent: Monday, February 13, 2006 11:15 AM
To: [hidden email]
Subject: Re: SSL_shutdown and SIGPIPE

Why are you trying to avoid SIGPIPE, anyway? It's easy to ignore, and
a global state would make it possible to determine what socket you
were writing on (if you needed that).

-Kyle H

On 2/12/06, Gayathri Sundar <[hidden email]> wrote:

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [hidden email]
Automated List Manager [hidden email]

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [hidden email]
Automated List Manager [hidden email]

Kyle Hamilton

Re: SSL_shutdown and SIGPIPE

In reply to this post by Alberto Alonso

SIGPIPE is a remnant of BSD attempting to overlay UNIX socket (named
pipe) semantics onto TCP/IP connections. If the socket that you are
writing to is a socket (or pipe), AND the pipe is closed, then you
receive a SIGPIPE.

In this case, the 'good reason' for it is that what you think is
supposed to be listening isn't listening anymore, so you may need to
update your internal state. However, since the other effect of
writing to a socket that is remote-closed is the descriptor itself
being closed, there's no reason to worry about it.

I help maintain a MUD software (that uses OpenSSL); often players will
disconnect by closing their clients instead of using the QUIT command,
and this leads to attempts to send information to them. When the
software receives the TCP RST ('connection reset by peer'), it also
receives a SIGPIPE. However, we have no need to deal with it, since
we check the return status of the write operation; if it fails, we
close the socket and clean up the memory allocated to that connection.

On 2/12/06, Alberto Alonso <[hidden email]> wrote:
> I personally don't know why pipes are even in use in the openssl
> internals (though I bet there is a good reason for it :-)

It's there because the underlying operating system forces them to be
there. It's certainly not at the behest of the OpenSSL team.

> Ignoring SIGPIPE (or most signals for that matter) is not really
> that good. They get generated for good reasons.

...explained above...

> In my case, depending on what came down the wire, I have to interact
> with other utilities in the system, therefore opening pipes. I need
> to make sure I get the signals when a system tool exits unexpectedly.

Alright, then just check to see what descriptor actually caused the
SIGPIPE (instead of setting it to SIG_IGN, you always have the ability
to write your own handler). If it's a descriptor that connects to
another utility, handle that special case (preferably by setting a
global variable and exiting the signal handler quickly, before
handling the exceptional circumstance in your main program loop --
this is akin to a 'deferred procedure call' in Windows 2000+ device
driver programming). If it's not, then it probably belongs to a
TLS/SSL connection, and can be safely ignored (since you're supposed
to be checking the return statuses of all of your OpenSSL calls
anyway, and since you're trying to shut down the SSL socket, you might
as well just call SSL_free() immediately after the SSL_shutdown
[taking into account the possibility of an SSL_WANTS_WRITE return
status].

-Kyle H
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [hidden email]
Automated List Manager [hidden email]

Girish Venkatachalam

Re: SSL_shutdown and SIGPIPE

None of the solutions suggested by others in the list
will protect you against a SIGPIPE for the simple
reason that it is a fatal signal if not handled or
ignored and it can come at any time during the TCP
session...

Ignoring SIGPIPE is one of the steps in writing a
server daemon and it is standard practice.

Best,
Girish

--- Kyle Hamilton <[hidden email]> wrote:

> SIGPIPE is a remnant of BSD attempting to overlay
> UNIX socket (named
> pipe) semantics onto TCP/IP connections. If the
> socket that you are
> writing to is a socket (or pipe), AND the pipe is
> closed, then you
> receive a SIGPIPE.
>
> In this case, the 'good reason' for it is that what
> you think is
> supposed to be listening isn't listening anymore, so
> you may need to
> update your internal state. However, since the
> other effect of
> writing to a socket that is remote-closed is the
> descriptor itself
> being closed, there's no reason to worry about it.
>
> I help maintain a MUD software (that uses OpenSSL);
> often players will
> disconnect by closing their clients instead of using
> the QUIT command,
> and this leads to attempts to send information to
> them. When the
> software receives the TCP RST ('connection reset by
> peer'), it also
> receives a SIGPIPE. However, we have no need to
> deal with it, since
> we check the return status of the write operation;
> if it fails, we
> close the socket and clean up the memory allocated
> to that connection.
>
> On 2/12/06, Alberto Alonso <[hidden email]>
> wrote:
> > I personally don't know why pipes are even in use
> in the openssl
> > internals (though I bet there is a good reason for
> it :-)
>
> It's there because the underlying operating system
> forces them to be
> there. It's certainly not at the behest of the
> OpenSSL team.
>
> > Ignoring SIGPIPE (or most signals for that matter)
> is not really
> > that good. They get generated for good reasons.
>
> ...explained above...
>
> > In my case, depending on what came down the wire,
> I have to interact
> > with other utilities in the system, therefore
> opening pipes. I need
> > to make sure I get the signals when a system tool
> exits unexpectedly.
>
> Alright, then just check to see what descriptor
> actually caused the
> SIGPIPE (instead of setting it to SIG_IGN, you
> always have the ability
> to write your own handler). If it's a descriptor
> that connects to
> another utility, handle that special case
> (preferably by setting a
> global variable and exiting the signal handler
> quickly, before
> handling the exceptional circumstance in your main
> program loop --
> this is akin to a 'deferred procedure call' in
> Windows 2000+ device
> driver programming). If it's not, then it probably
> belongs to a
> TLS/SSL connection, and can be safely ignored (since
> you're supposed
> to be checking the return statuses of all of your
> OpenSSL calls
> anyway, and since you're trying to shut down the SSL
> socket, you might
> as well just call SSL_free() immediately after the
> SSL_shutdown
> [taking into account the possibility of an
> SSL_WANTS_WRITE return
> status].
>
> -Kyle H
>

Girish Venkatachalam

Re: SSL_shutdown and SIGPIPE

In reply to this post by Kyle Hamilton

Girish Venkatachalam

Re: SSL_shutdown and SIGPIPE

In reply to this post by Kyle Hamilton

--- Kyle Hamilton <[hidden email]> wrote:

Girish Venkatachalam

Re: SSL_shutdown and SIGPIPE

In reply to this post by Kyle Hamilton

SIGPIPE is fatal if not handled or ignored and it can
come at any time during the TCP session. Which means
that none of the solutions suggested by others in the
list will work.

And it is wrong to rely on OpenSSL for solving a TCP
closure at the remote end which is essentially a TCP
issue.

write() or read() will return a 0 or -1 on a closed
socket, so you stand to lose nothing by ignoring
SIGPIPE.

regards,
Girish

--- Kyle Hamilton <[hidden email]> wrote:

Rick Jones-2

Re: SSL_shutdown and SIGPIPE

In reply to this post by Gayathri Sundar-2

Gayathri Sundar wrote:
> Probably you can call the following
>
> iRet = SSL_get_shutdown(pSSL);
> if(iRet >= 0) SSL_shutdown(pSSL);
>
> This is because, SSL_shutdown writes data on the wire,
> i.e the closure alerts..and if a FIN was received meanwhile,
> you will catch a SIGPIPE..this piece of code, actually
> saves me from this..

Strictly speaking, it isn't that a FIN was received. Receipt of the FIN in and
of itself does not mean that the remote TCP endpoint is gone, nor that it is
unwilling to accept more data. All a FIN means in and of itself is that the
remote TCP and application will be sending no more data our way on the
connection. For example, when the remote simply calls shutdown(SHUT_WR).

Now, we also receive a FIN when the remote calls close(). In this sitation,
while it was unable to communicate that via TCP, the remote is not willing to
recieve any more data. The close() has implicitly stated such to the remote
TCP, so when the remote TCP recieves our data, it becomes
upset/worried/concernec/confused tosses its hands in the air and sends us a RST
segment. Receipt of that RST segment puts our end of the TCP connection into an
aborted state, and an attempt to write to the socket generates the SIGPIPE.
Generally, this will not be seen by us until our _second_ access of the socket -
first the write to trigger the RST from the remote, and then some other socket
call - typically another write IIRC, but I think it could be a recv.

SIGPIPE/EPIPE is our local TCP's way of telling us that we screwed-up in the
application-level handshaking between the ends.

A variation of the close() scenario is if the remote application is (bogusly
IMO) using an "abortive close" a la SO_LINGER. In that case they emit a RST and
go away. Either we receive that RST and go SIGPIPE/EPIPE on the next socket
call, or we don't see that RST (it is lost) and we follow a path much like the FIN.

The only way to be more or less sure we won't get an EPIPE/SIGPIPE is to preface
all our socket calls with something like select() or poll(), and even then there
is still a small window of a race condition, and of course the slight matter of
the select/poll overhead...

rick jones
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [hidden email]
Automated List Manager [hidden email]

Rick Jones-2

Re: SSL_shutdown and SIGPIPE

In reply to this post by Girish Venkatachalam

Girish Venkatachalam wrote:
> SIGPIPE is fatal if not handled or ignored and it can
> come at any time during the TCP session. Which means
> that none of the solutions suggested by others in the
> list will work.
>
> And it is wrong to rely on OpenSSL for solving a TCP
> closure at the remote end which is essentially a TCP
> issue.

Not to say that OpenSSL is or is not partially culpable, but things like
SIGPIPE/EPIPE are not _solely_ the responsibility of TCP. Connection close
handshaking is the joint responsibility of TCP and its user.

rick jones
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [hidden email]
Automated List Manager [hidden email]

Alberto Alonso

Re: SSL_shutdown and SIGPIPE

In reply to this post by Kyle Hamilton

Thanks for the detailed explanation, it clearly helped my
understanding of the whole thing.

I obviously already have a SIGPIPE handler, but the difficulty
comes from trying to figure out which call generated the signal.

As the code is meant to work on Linux and windows, and my understanding
is that the windows pthreads implementation doesn't do per thread
signals it becomes even more difficult to pinpoint the culprit.

Proper checking of all the return codes helps (and that's what I've
been doing anyway). I was trying to use a SIGPIPE as an indication of a
problem with the system tools interaction, but it is clear now that
it was a simplistic approach.

Thanks,

Alberto

On Mon, 2006-02-13 at 06:42 -0700, Kyle Hamilton wrote:

> SIGPIPE is a remnant of BSD attempting to overlay UNIX socket (named
> pipe) semantics onto TCP/IP connections. If the socket that you are
> writing to is a socket (or pipe), AND the pipe is closed, then you
> receive a SIGPIPE.
>
> In this case, the 'good reason' for it is that what you think is
> supposed to be listening isn't listening anymore, so you may need to
> update your internal state. However, since the other effect of
> writing to a socket that is remote-closed is the descriptor itself
> being closed, there's no reason to worry about it.
>
> I help maintain a MUD software (that uses OpenSSL); often players will
> disconnect by closing their clients instead of using the QUIT command,
> and this leads to attempts to send information to them. When the
> software receives the TCP RST ('connection reset by peer'), it also
> receives a SIGPIPE. However, we have no need to deal with it, since
> we check the return status of the write operation; if it fails, we
> close the socket and clean up the memory allocated to that connection.
>
> On 2/12/06, Alberto Alonso <[hidden email]> wrote:
> > I personally don't know why pipes are even in use in the openssl
> > internals (though I bet there is a good reason for it :-)
>
> It's there because the underlying operating system forces them to be
> there. It's certainly not at the behest of the OpenSSL team.
>
> > Ignoring SIGPIPE (or most signals for that matter) is not really
> > that good. They get generated for good reasons.
>
> ...explained above...
>
> > In my case, depending on what came down the wire, I have to interact
> > with other utilities in the system, therefore opening pipes. I need
> > to make sure I get the signals when a system tool exits unexpectedly.
>
> Alright, then just check to see what descriptor actually caused the
> SIGPIPE (instead of setting it to SIG_IGN, you always have the ability
> to write your own handler). If it's a descriptor that connects to
> another utility, handle that special case (preferably by setting a
> global variable and exiting the signal handler quickly, before
> handling the exceptional circumstance in your main program loop --
> this is akin to a 'deferred procedure call' in Windows 2000+ device
> driver programming). If it's not, then it probably belongs to a
> TLS/SSL connection, and can be safely ignored (since you're supposed
> to be checking the return statuses of all of your OpenSSL calls
> anyway, and since you're trying to shut down the SSL socket, you might
> as well just call SSL_free() immediately after the SSL_shutdown
> [taking into account the possibility of an SSL_WANTS_WRITE return
> status].
>
> -Kyle H
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List [hidden email]
> Automated List Manager [hidden email]