operations.
Application is crashing because of a call to SSL_shutdown().
Gdb trace is shown below.
(gdb) bt
#0 0x42926357 in raise () from /lib/libc.so.6
#1 0x42929962 in abort () from /lib/libc.so.6
#2 0x77453e7a in OpenSSLDie () from
/home/SYSROM_SRC/build/release/lib/libcrypto.so.1.0.0
Hi!
Is this supposed to happen ?
I have a SSL Server writting to a client.
I was expecting that if, at a random time (user initiated) the client would
call SSL_Shutdown,
then the Server would `see' the shutdown by calling SSL_get_shutdown
But that never happens.
If I keep calling Shutdo
On 21/04/2017 01:35, Linsell, StevenX wrote:
On 20/04/2017, Bohn, Jakob wrote:
Let me clarify: The idea was not to change the synchronization structure,
but to set a flag or otherwise (asynchronously or in a small critical
section) change the state such that when the communication async
operati
otype that did that but it's something
that is still on my list of things to try out.
>This serves two purposes: To make the "SSL_shutdown" call "just work"
>from an application perspective, and to minimize security exposure
>after the call has been made (e.
not process the bytes in that
hello, but respond as if it received a bad hello (with
"aborted/closed" rather than "invalid hello" as the error/alert
code). It would not proceed to e.g. validate incoming public keys,
send public keys, generate nonces, derive keys etc.
This serves tw
On 19/04/2017, Bohn, Jakob via openssl-users wrote:
> On 19/04/2017 14:35, Salz, Rich via openssl-users wrote:
> >> The OpenSSL documentation makes it clear that you must keep calling
> >> the same asynchronous function with the same parameters until the
> >> async job has completed.
> > Is there
On 19/04/2017 14:35, Salz, Rich via openssl-users wrote:
The OpenSSL documentation makes it clear
that you must keep calling the same asynchronous function with the same
parameters until the async job has completed.
Is there a way we can (relatively cheaply) check for that type of programming er
> The OpenSSL documentation makes it clear
> that you must keep calling the same asynchronous function with the same
> parameters until the async job has completed.
Is there a way we can (relatively cheaply) check for that type of programming
error and return an "in progress on another op" error
->
>
>//client want to close the connection, then, server should close ssl
>connection ,In program, I intend to close SSL connections in quiet mode?
>SSL_set_quiet_shutdown(ssl,1);
>SSL_shutdown(ssl);
>
>but SSL_shutdown returns SSL_ERROR_SSL, because SSL_in_init(s)
>
//client want to close the connection, then, server should close ssl connection
,In program, I intend to close SSL connections in quiet mode：
SSL_set_quiet_shutdown(ssl,1);
SSL_shutdown(ssl);
but SSL_shutdown returns SSL_ERROR_SSL, because SSL_in_init(s) return true.
int SSL_shutdown(
finishes) I close connection 1.
The problem I am facing is SSL_shutdown is returning error (return
code < 0). Most of the time it works, and I am successfully able to
communicate over connection 2 after connection 1 has been closed. But
suddenly once out of the blue it returns error. Subsequent SSL_r
t; I have not kept the test for s being NULL, as that case would
> have crashed a few lines earlier in SSL_shutdown(), so can't
> reach the if statement anyway.
>
> I have attached the reduced patch, but I still think the real
> cause must be elsewhere.
I am currently pu
crashed a few lines earlier in SSL_shutdown(), so can't
reach the if statement anyway.
I have attached the reduced patch, but I still think the real
cause must be elsewhere.
On 02/02/2016 12:34, Matt Caswell wrote:
On 02/02/16 11:24, Jakob Bohm wrote:
On 02/02/2016 11:40, Matt Caswell
gt;> I am unsure if this exposed a bug in the daemon or in OpenSSL
>>> itself.
>> I have a theory.
>>
>> Previous versions of 1.0.2 handled an SSL_shutdown() call while in the
>> middle of a handshake by ignoring it and returning 1 immediately
>> (meaning everythi
tify alert unencrypted followed
by an encrypted decrypt_failed alert, where 1.0.2c correctly
sends just an encrypted close_notify alert.
I am unsure if this exposed a bug in the daemon or in OpenSSL
itself.
I have a theory.
Previous versions of 1.0.2 handled an SSL_shutdown() call while in the
m
ncrypted followed
> by an encrypted decrypt_failed alert, where 1.0.2c correctly
> sends just an encrypted close_notify alert.
>
> I am unsure if this exposed a bug in the daemon or in OpenSSL
> itself.
I have a theory.
Previous versions of 1.0.2 handled an SSL_shutdown() call while in
I am trying to upgrade an existing 3rd party multithreaded server
from OpenSSL 1.0.2c to 1.0.2f . However when I do so, it starts
mishandling the close_notify "alert".
1.0.2f seems to send the close_notify alert unencrypted followed
by an encrypted decrypt_failed alert, where 1.0.2c correctly
se
I'm using SSL over non-blocking socket. As a result SSL_shutdown returns
immediately with error code 5 (underlying socket issue), sometimes after
doing this, the program crashes on SSL_CTX_free.
So I was wondering about closing the socket without doing an
SSL_shutdown. Is this safe
On Thu, Oct 24, 2013 at 03:59:08PM -0400, Dave Thompson wrote:
>0 The shutdown is not yet finished. Call SSL_shutdown() for a
> second
>time, if a bidirectional shutdown shall be performed. The output
>of SSL_get_error(3) may be misleading, as
> From: owner-openssl-users On Behalf Of Dave Mitchell
> Sent: Thursday, October 24, 2013 06:25
> On Sun, Oct 20, 2013 at 09:29:53PM +0100, Dave Mitchell wrote:
> > The man page for SSL_get_error() lists the SSL_* functions it can be
used
> > with, and it doesn&#
On Sun, Oct 20, 2013 at 09:29:53PM +0100, Dave Mitchell wrote:
> The man page for SSL_get_error() lists the SSL_* functions it can be used
> with, and it doesn't mention SSL_shutdown().
>
> On the other hand, the man page for SSL_shutdown() says that for
> non-blocking
The man page for SSL_get_error() lists the SSL_* functions it can be used
with, and it doesn't mention SSL_shutdown().
On the other hand, the man page for SSL_shutdown() says that for
non-blocking I/O, you should call SSL_get_error().
So which is right?
I ask, because in the following
Hi All,
I am using openssl-1.0.1c in our project.when SSL_shutdown(ssl) get
executed it returns 0.If I get return value zero then calling the same
SSL_shutdown(ssl) again.In 2nd time it return -1/SSL_ERROR_WANT_READ. Now I
am doing SSL_read(), but it returns -1.Again I am calling
Priyaranjan Nayak wrote:
I am using openssl-1.0.1c in our project.when SSL_shutdown(ssl)
get executed it returns 0.If I get return value zero then calling the
same SSL_shutdown(ssl) again.In 2nd time it return -1. Can any one tell
me how to shutdown ssl context ? How can I execute
YUN GAO wrote:
Hi there:
SSL_shutdown used to have a problem that in some instances it always
returns 0 no matter how many time it is called before 0.9.8l.
To solve the issue, I have to call SSL_shutdown() twice and check the
error number and return code at the second time: if the return code
is
Hi All,
I am using openssl-1.0.1c in our project.when SSL_shutdown(ssl) get
executed it returns 0.If I get return value zero then calling the same
SSL_shutdown(ssl) again.In 2nd time it return -1. Can any one tell me how
to shutdown ssl context ? How can I execute SSL_shutdown(ssl) , so
Hi Scott!
> When it is time to cleanly close the connection, it calls SSL_shutdown(),
> then returns to its select loop to wait for a response indicating that the
> server has completed its end of the shutdown. When the server has
> completed the shutdown, it expects select to r
ular server.
The client wrapper uses blocking socket BIOs in a select(2) loop.
When it is time to cleanly close the connection, it calls SSL_shutdown(),
then returns to its select loop to wait for a response indicating that the
server has completed its end of the shutdown. When the server has co
Which code you want, my application is very big?
Just the code to call, SSL_shutdown from client side is pasted in this.
http://pastebin.com/7P70aNWU
On Tue, May 3, 2011 at 12:35 PM, derleader mail wrote:
> Hi,
>I am using Blocking sockets for my applicaiton. The server i have
Hi,
I am using Blocking sockets for my applicaiton. The server i have accept SSL
and non SSL connections, from the client side when i connect with SSL then on
closesocket i dont get a notification of client closed, while for non SSL i get
notification. Is this some desired behavior or i am
Hi,
I am using Blocking sockets for my applicaiton. The server i have accept
SSL and non SSL connections, from the client side when i connect with SSL
then on closesocket i dont get a notification of client closed, while for
non SSL i get notification. Is this some desired behavior or i am missi
Antoine Pitrou wrote:
Well, in our case, and unless I'm mistaken,
ret == -1, ERR_get_error() == 0 and then errno (the Unix errno) == 0.
SSL_shutdown() by virtue of its unique mechanic you will not see "ret ==
0" (in the way the SSL_get_error man page describes) since that has a
Hello again,
> I have investigated this issue of -1/SSL_ERROR_SYSCALL with errno==0.
>
>
> From the SSL_get_error(3) man page:
>
> SSL_ERROR_SYSCALL
> Some I/O error occurred. The OpenSSL error queue may contain more
> information on the error. If the error queue is empty (i.e.
> ERR_
et, which would have
been caused by the far end calling SSL_shutdown() at least once). You
have used the term "errno" where really OpenSSL talks in terms of the
error codes off the error stack.
I also note the man page doesn't include SSL_shutdown() in the very
specific list of
ce of events.
I have an SSL protocol test-case creator that can manipulate both ends
OpenSSL API usage in a co-ordinated fashion, it should be straight
forward to cause an abrupt socket closure around/during SSL_shutdown()
usage.
Ok, thanks for the clarification. We were a bit baffled by err
OpenSSL 0.9.8m.
(there are also a couple of 1.0.0-specific issues which seem
negotation-related, and which we'll have to tackle separately)
> What SSL_shutdown() is saying by returning -1/ERROR_SYSCALL is that a
> cryptographically two-way shutdown of the stream was _NOT_ completed and
Long info because I fear the Python module maybe misunderstanding what
SSL_shutdown() actually does and why it exists. Which in turn mean that
users of the Python module also misuse it (sandcastles in the sand and
all that).
Antoine Pitrou wrote:
While testing Python's SSL support
modules myself but I believe this user was also debugging a
similar issue.
http://www.mail-archive.com/openssl-users@openssl.org/msg60444.html
"Problems with SSL_shutdown() and non blocking socket" from "Victor
Stinner" on 12-Mar-2010.
Please collaborate with the officia
Hello,
While testing Python's SSL support with OpenSSL >= 0.9.8m, we have
encountered a strange error return from SSL_shutdown on a non-blocking
socket (note: this is a different problem from the one described by
Victor Stinner in an earlier thread last month). Basically:
- SSL_
On Tue, Mar 23, 2010, Dr. Stephen Henson wrote:
> Another possible cause is multiple closes on the same file descriptor in a
> multi threaded application. I saw this once myself where the SSL_free() closed
> the file descriptor and the application itself closed it as well.
The application is send
hat it's worth, Postfix calls SSL_shutdown via a biopair state
machine that handles SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE.
/* The TLS layer to network interface is realized with a BIO pair:
/*
/* Postfix SMTP layer | TLS layer
/*
so print out the %p or %d value of their first and/or return values
> arguments as well:
>
> %p = SSL_new(...)
> SSL_set_fd(%p, %d)
> SSL_set_rfd(%p, %d)
> SSL_set_wfd(%p, %d)
> SSL_shutdown(%p, ...)
> SSL_free(%p, ...)
> close(%d)
>
>
> Note there are other ways to sk
f the
following API calls would highlight the out-of-order problem, I'd advise
you also print out the %p or %d value of their first and/or return
values arguments as well:
%p = SSL_new(...)
SSL_set_fd(%p, %d)
SSL_set_rfd(%p, %d)
SSL_set_wfd(%p, %d)
SSL_shutdown(%p, ...)
SSL_free(%
On Fri, Mar 12, 2010, Darryl Miles wrote:
> int rc = SSL_shutdown(ssl);
> /* BEGIN - INSERT THIS CODE AFTER EVERY SSL_shutdown()
> INVOCATION IN YOUR CODE */
> if(rc == -1) {
> int ssl_errno;
> SSL_get_error(ssl, ssl_errno);
> if(ssl_errno =
de of Python shutdown low-level function:
err = SSL_shutdown(self->ssl);
if (err == 0)
err = SSL_shutdown(self->ssl);
if (err < 0)
else
Using OpenSSL 0.9.8m, SSL_shutdown() returns sometimes -1 and SSL_get_
tdown low-level function:
err = SSL_shutdown(self->ssl);
if (err == 0)
err = SSL_shutdown(self->ssl);
if (err < 0)
else
Using OpenSSL 0.9.8m, SSL_shutdown() returns sometimes -1 and SSL_get_error()
gives SSL_ERROR_W
Forwarded to openssl-users for public discussion.
Best regards,
Lutz
- Forwarded message from Xavier De Kepper -
From: Xavier De Kepper
To: "r...@openssl.org"
Date: Fri, 27 Nov 2009 02:15:17 -0800
Subject: Question on SSL_shutdown timeout
Thread-Topic: Question on SS
Hi,
Can any one tell when where can I see the implemenataion of SSL API "
SSL_shutdown "
Thanks in advance.
--
View this message in context:
http://www.nabble.com/Implementation-of-API-SSL_shutdown-tp25380103p25380103.html
Sent from the OpenSSL - User mailing list archive at
ent: 19 May 2009 12:50
> To: openssl-users@openssl.org
> Subject: (SCL: 1) Re: SSL_CTX_load_verify_locations was SSL_shutdown
> never returns 1
>
> Ummm... could you resend this, in something intelligible? :)
>
> -Kyle H
>
> On T
t;leak".
> -Original Message-
> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> us...@openssl.org] On Behalf Of Kyle Hamilton
> Sent: 19 May 2009 12:49
> To: openssl-users@openssl.org
> Subject: Re: SSL_shutdown never returns 1
>
> When you get an
Ummm... could you resend this, in something intelligible? :)
-Kyle H
On Tue, May 19, 2009 at 4:16 AM, Andy Murphy wrote:
> V2VsbCBJJ3ZlIGZvdW5kIG91dCB3aGF0IGlzIHRha2luZyB0aGUgbWVtb3J5IGFuZCBpdCdzIHRo
> aXM6IFNTTF9DVFhfbG9hZF92ZXJpZnlfbG9jYXRpb25zLiAgSSdtIGNhbGxpbmcgaXQgZm9yIGVh
> Y2ggU1NMX0NUWCw
; Thanks for any help you can give.
>
> Andy
>
>
>> -Original Message-
>> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
>> us...@openssl.org] On Behalf Of Kyle Hamilton
>> Sent: 14 May 2009 18:10
>> To: openssl-users@openssl.org
>
mory after I've done with a
ping? I can't see anything in the documentation.
Thanks
Andy
> -Original Message-
> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> us...@openssl.org] On Behalf Of Andy Murphy
> Sent: 19 May 2009 10:15
> To: openssl-u
ny help you can give.
Andy
> -Original Message-
> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> us...@openssl.org] On Behalf Of Kyle Hamilton
> Sent: 14 May 2009 18:10
> To: openssl-users@openssl.org
> Subject: Re: SSL_shutdown never returns 1
>
> I
own to us not using the word virtual on
> our base class’ destructor, so I’m not about to start blaming OpenSSL again
> J.
>
>
>
> I have however seen from some other threads that if SSL_shutdown does not
> return 1 then there could be a leak. Our logs show that two attempts t
o start
blaming OpenSSL again J.
I have however seen from some other threads that if SSL_shutdown does
not return 1 then there could be a leak. Our logs show that two
attempts to call SSL_shutdown do not result in 1 coming back and I've
just tried it in a never-ending while loop and well, it nev
Hi,
I have an SSL server that runs fine on Windows and on Linux. However
on Solaris and IBM platforms, if the client is a windows one, my
server crashes when the client exits.
I was able to track the crash to the second call of SSL_shutdown below
in my server code:
r=SSL_shutdown(ssl);
if(!r
-- Original Message --
To: (openssl-users@openssl.org)
From: Saju ([EMAIL PROTECTED])
Subject: RE: SSL_shutdown
Date: 10/2/2008 3:52:05p
> Connection shutdown is just:
> Library->BIO_ssl_shutdown(Bio);
> Library->BIO_set_close(Bio,BIO_CLOSE);
Connection shutdown is just:
Library->BIO_ssl_shutdown(Bio);
Library->BIO_set_close(Bio,BIO_CLOSE);
Library->BIO_free_all(Bio);
//if (Library->SSL_shutdown(Ssl) == 0)
// Library->SSL_shutdown(Ssl);
// Library->SSL_free(Ssl);
Hi,
I'm developing an email application that uses OpenSSL (0.9.7?) and I'm having
problems on MacOSX (tiger). Basically after the connection is finished I called
SSL_shutdown, check the return code and if zero I call it again... just once.
After all this everything appears to be
Hi
I need your help on SSL_shutdown(). . The Client send "close notify" to
server first to initiates the close connection. This first call return
0 , which it is correctly. Then The Client call SSL_shutdown again to
wait for "close notify" form Server. The second SSL_sh
I use openssl 0.9.7d on both multithreaded windows XP client and linux
server.
The windows client will hang or crash (at SSL_shutdown or SSL_pending) after
running from several minutes to several hours.
The linux server is still up and running.
The windows client can be restarted without any
.
The problem:
* I make the call to SSL_shutdown() for the first time and get the
expected return value of zero.
* To indicate that I have sent my notify.
* My code then calls SSL_shutdown() for the second time but there is no
data available just yet (expecting recv close notify) you can see the
I'm writing a server with OpenSSL 0.9.8a. When calling SSL_shutdown() to
send a close_notify responding to a previous one from the client, a 0
was returned.
After some investigation, the reason was found to be the underlying
nonblocking BIO was not able to satisfy ssl3_write_pending(). Acco
t; 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
&g
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, actua
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 e
--
> 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
f 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,
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
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
o 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
st
:[EMAIL PROTECTED] Behalf Of Kyle Hamilton
Sent: Monday, February 13, 2006 11:15 AM
To: openssl-users@openssl.org
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 wr
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
nd
> 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 <[EMAIL PROTECTED]> wrote:
> > Probably you can call the following
> >
> > iRet = SSL_get_shutdown(pSSL)
Excellent, I'll give this a try.
Thanks,
Alberto
On Mon, 2006-02-13 at 10:51 +0530, 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 t
owing
>
> 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..
&g
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 t
AIL PROTECTED]> 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
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
would be better to call SSL_shutdown() in the client
when it is complete. In the server you can call SSL_get_shutdown()
when you expect the client may disconnect. In the server it should
be fine to call SSL_shutdown() anyway. I don't think the SSL
specification defines whether the server
Hi,
If I understand it correctly the close_notify alert is only there to
prevent a truncation attack. If your higher level protocol can
check that all expected data is present then it is OK just to
close the socket.
To be safe it would be better to call SSL_shutdown() in the client
when it is
ve you set the "quiet shutdown" mode in ur ctx?
if that is set, then the alert will not be sent on the wire..
This is what I get from man SSL_shutdown
SSL_shutdown() tries to send the "close notify" shutdown alert to the
peer. Whether the operation succeeds or not, the SSL_S
I think I understand but I still seem to have an issue with my code.
1). Server opens an SSL port for a client to connect to
2). Client connects to this port and SSL_read and Write stuff.
3). Client Calls SSL_shutdown( sslSocket );
4). Server Calls SSL_get_shutdown( sslSocket ), If shutdown is
you should cleanup or select for a timeout.
This code snippet is true for blocking sockets.
Thanks
--Gayathri
I am confused.
If SSL_shutdown returns 0 then I need to call SSL_shutdown again? So
would I do something like this on the client side?
/* Client code to close SSL connection
I am confused.
If SSL_shutdown returns 0 then I need to call SSL_shutdown again? So
would I do something like this on the client side?
/* Client code to close SSL connection */
if( (SSL *)NULL != *sslSocket )
{
if( SSL_ST_OK == SSL_state( *sslSocket ) )
{
status
On Mon, Dec 19, 2005 at 11:22:11AM -0500, Perry L. Jones wrote:
> I have some questions about shutting down an SSL connection.
>
The correct use of SSL_shutdown() is described in the SSL_shutdown
manpage. Read the whole thing, and pay specific attention to:
When the application
Hello,
I have some questions about shutting down an SSL connection.
I am using TLS for the communication protocol and I am doing the
following to close my SSL socket.
if( (SSL *)NULL != *sslSocket )
{
if( SSL_ST_OK == SSL_state( *sslSocket ) )
{
SSL_shutdown( *sslSocket
Hi!
II want to restart the same SSL session
after calling SSL_shutdown(). I tried the following but it got stuck at
SSL_connect(). I wonder if I can do either of the following on the client:
1) Call SSL_shutdown() but then reuse
the same SSL object for a later SSL_connect().
or
2) Call
e shutdown when
SSL_shutdown returns 0.
The manual claims:
0 The shutdown is not yet finished. Call SSL_shutdown() for a
second
time, if a bidirectional shutdown shall be performed. The
output
of SSL_get_error(3) may be misleading, as an erroneous
SSL_ERR
Err#32 EPIPE
And pfiles shows that FD 13 is a disconnected socket:
13: S_IFSOCK mode:0666 dev:290,0 ino:46258 uid:0 gid:0 size:0
O_RDWR|O_NONBLOCK FD_CLOEXEC
sockname: AF_INET 0.0.0.0 port: 0
The stunnel log shows entry after entry like this:
2005.03.25 17:31:40 LOG7[3208:6]: SS
On Thu, Jul 03, 2003 at 10:47:27PM -0400, Thomas J. Hruska wrote:
> For non-blocking BIOs (in this case, non-blocking sockets), the
> documentation is unclear as to whether or not a second call to
> SSL_shutdown() will block:
>
> "The second call will make SSL_shutdown()
For non-blocking BIOs (in this case, non-blocking sockets), the
documentation is unclear as to whether or not a second call to
SSL_shutdown() will block:
"The second call will make SSL_shutdown() wait for the peer's "close
notify" shutdown alert. On success, the second
tten = SSL_write ( m_SecureConnection, pBuffer, dwBufferSize );
if ( nBytesWritten > 0) {...}
This is also working well.
UNFORTUNATELY the next code fails. When I'm tryieng to finish connection I get
SSL_ERROR_SYSCALL: rc = SSL_shutdown ( m_SecureConnection );
if (rc == 0)
{
// as sugg
Hello
Why should I use SSL_shutdown ? I mean, I have successfully used the
closesocket() operations under win98 (async sockets) and the client
and server apps are just fine with closing the connection in this
manner, so why do I need SSL_shutdown for ? I know it's not
secured against a &
On Thu, Aug 23, 2001 at 01:17:17PM -0400, George Lind wrote:
> I am running openssl on an NT machine. I am trying to transfer a file to an
> IBM mainframe which is using IBM's implementation of SSL. When I issue an
> SSL_shutdown the mainframe does not have the ability to
I am running openssl on an NT machine. I am trying to transfer a file to an
IBM mainframe which is using IBM's implementation of SSL. When I issue an
SSL_shutdown the mainframe does not have the ability to send back the
shutdown notification so the NT side hangs waiting for a response.
Good job Lutz!
There is, however, one ambiguity. The paragraph:
If the peer already sent the "close notify" alert and it was already
processed implicitly inside another call of e.g. SSL_read(3)|SSL_read(3),
SSL_shutdown() will send the "close notify" alert, set the SSL_SE
ribution.
SSL_get_shutdown() is described in the SSL_set_shutdown manual page.
I will follow your proposal and and add a corresponding note to
the SSL_shutdown manual page.
That example programs directly manipulate ssl->shutdown is a bad idea.
Things grew over time and would probably need some overha
Lutz Jaenicke wrote,
> During the last week I have rewritten the manual page for
> SSL_shutdown(), please use the online version or download a snapshot
> of OpeSSL to obtain it. It probably contains the answer to your
> question.
The new man page is a huge improvement ... thanks.
1 - 100 of 111 matches
Mail list logo
