With the announcement of OpenSSL 1.0.0 on the way, may I attempt to get
some attention on this issue for which:
* a patch exists
* a test case exists (that exposes the problem, that verifies the fix
doesn't break anything)
* multiple users have shared their concern over the years (some
On Tue, Apr 07, 2009, Darryl Miles wrote:
With the announcement of OpenSSL 1.0.0 on the way, may I attempt to get
some attention on this issue for which:
* a patch exists
* a test case exists (that exposes the problem, that verifies the fix
doesn't break anything)
* multiple users
On Mon, Oct 01, 2007 at 08:06:04PM +0100, Darryl Miles wrote:
Would Davide be so kind as to look over the following openssl-dev list
post for the semantics I suggest and confirm that logic would work for him:
http://marc.info/?l=openssl-devm=115153998821797w=2
The archive at marc.info
Try next_in_thread, take a look at the thread views (by clicking the
subject line) you get to:
http://marc.info/?t=11515400401r=1w=2
For background reading see also the threads:
http://marc.info/?l=openssl-usersm=115088475305680w=2
http://marc.info/?t=11509972822r=1w=2
Darryl Miles wrote:
Nanno Langstraat wrote:
So I can add one more voice to the choir: the current SSL_shutdown()
API appears to give trouble to every non-blocking developer (I
remember I lost serious time noticing + tracking down this 100% CPU
bug), and afterwards things still don't really
This goes pear-shaped as follows:
* The SSL connection is made and used
* The remote side closes its file descriptor (e.g. process killed,
TCP shutdown(RD))
* Local SSL_read() returns 0. The app event loop sets a flag and
makes sure it never calls SSL_read() again.
Nanno Langstraat wrote:
It turns out that the problem does *not* directly involve
SSL_shutdown(), but it *is* attributable to OpenSSL, and specifically
OpenSSL's non-blocking shutdown semantics.
Okat thats cleared that up, it is indeed unrelated to the OP of this
thread. Please move replies
David Schwartz wrote:
This goes pear-shaped as follows:
The application is broken. Once SSL_read returns 0, the connection is dead.
Quote chapter and verse of the OpenSSL API documentation, or desist from
such vehement statements.
You can not scold an API user for violating rules
Nanno Langstraat wrote:
David Schwartz wrote:
The socket is not and never again will be readable. It's passed on. It's
bereft of life. It's not pinin' for the fjords. Etc.
And more importantly, OpenSSL is the only party who knows this
underlying cause, and SSL_want_read() is the designated
Nanno Langstraat:
Quote chapter and verse of the OpenSSL API documentation, or desist from
such vehement statements.
You can not scold an API user for violating rules that are not in the
documentation.
I already claimed that the application programmer is not given the
knowledge that this
Darryl Miles wrote:
David Schwartz wrote:
If I'm misunderstanding the man page and/or the source code
please speak up.
My man page says:
If the underlying BIO is non-blocking, SSL_shutdown() will also
Yes but what SSL_shutdown() actually does is always return 0
This discussion a
Nanno Langstraat wrote:
So I can add one more voice to the choir: the current SSL_shutdown() API
appears to give trouble to every non-blocking developer (I remember I
lost serious time noticing + tracking down this 100% CPU bug), and
afterwards things still don't really work right.
I can't
Darryl Miles wrote:
2) SSL_read() already has a return value -1/ZERO_RETURN which indicates
end-of-stream. You may then call SSL_shutdown() to look to see if 1 is
returned or not. Or even SSL_get_shutdown() and take whatever security
action your application needs to take in the event of an
On Mon, 1 Oct 2007, Richard Salz wrote:
If that's an example of working API for someone, it's no surprise
websphere blows.
There's no need to be rude.
And WebSphere doesn't use OpenSSL.
It was not me that showed up throwing titles, an sigs to look up. I tried
to keep the conversation
What is the difference between this an my patch from a year or so ago ?
http://marc.info/?t=11509972822r=1w=2 '[PATCH] Fix for
SSL_shutdown() with non-blocking not returning -1'
http://marc.info/?t=11515400401r=1w=2 '[PATCH2] Fix for
SSL_shutdown() with non-blocking not returning
Davide Libenzi wrote:
On Sat, 29 Sep 2007, Richard Salz wrote:
I seriously doubt ppl are using SSL_shutdown() with non-blocking BIOs,
together with the current API semantics. Seriously.
Are you new here? This library has been around for more than a decade.
There are *lots* of people using
Richard Salz wrote:
double/triple check over it). Whatever fix you guys come up with, as
long
as SSL_shutdown() ends up having sane (somehow aligned to SSL_read,
SSL_write, etc...) semantics WRT non-blocking BIOs.
Nope. Maybe a new shutdown that has your semantics, but do not break
On Mon, 1 Oct 2007, Darryl Miles wrote:
The Are you new here? I find somewhat offputting, even through it was not
directed at me. Richard is obviously old here and set in his ways and thinks
that his OpenSSL library is better than it actually is.
Oh, don't worry about that ;) I'm used to ml
On Mon, 1 Oct 2007, Darryl Miles wrote:
Richard Salz wrote:
double/triple check over it). Whatever fix you guys come up with, as
long
as SSL_shutdown() ends up having sane (somehow aligned to SSL_read,
SSL_write, etc...) semantics WRT non-blocking BIOs.
Nope. Maybe a new
Davide Libenzi wrote:
Can this be worked around? Sure. With some woodoo/ugly magic code in the
async status code handling. You *cannot* always wait for readwrite, since
you'll be exiting the event selection loop immediately, every time.
You need to bolt-in the shutdown logic *outside* the
If I'm misunderstanding the man page and/or the source code
please speak up.
My man page says:
If the underlying BIO is non-blocking, SSL_shutdown() will also
return
when the underlying BIO could not satisfy the needs of SSL_shutdown()
to continue the handshake. In this
David Schwartz wrote:
If I'm misunderstanding the man page and/or the source code
please speak up.
My man page says:
If the underlying BIO is non-blocking, SSL_shutdown() will also
return
when the underlying BIO could not satisfy the needs of SSL_shutdown()
to continue
On Mon, 1 Oct 2007, Darryl Miles wrote:
Davide Libenzi wrote:
Can this be worked around? Sure. With some woodoo/ugly magic code in the
async status code handling. You *cannot* always wait for readwrite, since
you'll be exiting the event selection loop immediately, every time.
You need to
If that's an example of working API for someone, it's no surprise
websphere blows.
There's no need to be rude.
And WebSphere doesn't use OpenSSL.
/r$
--
STSM, DataPower Chief Programmer
Websphere DataPower SOA Appliances
http://www.ibm.com/software/integration/datapower/
Wait for both, keep your own state. Works well enough. See the products
at the URL in my .sig for proof :)
/r$
--
STSM, DataPower Chief Programmer
Websphere DataPower SOA Appliances
http://www.ibm.com/software/integration/datapower/
On Sun, 30 Sep 2007, Richard Salz wrote:
Wait for both, keep your own state. Works well enough. See the products
at the URL in my .sig for proof :)
Wow! That *really* impressed me.
So, besides throwing titles and sigs, can you show how easily can you cope
with the current SSL_shutdown()
Would it be possible to make SSL_shutdown() on non-blocking BIOs, conform
to the documentation and aligned to SSL_read, SSL_write, ...?
http://www.openssl.org/docs/ssl/SSL_shutdown.html
I cooked a tentative patch below, that seems to be working here.
It definitely need double check from someone
On Sat, Sep 29, 2007 at 01:19:38PM -0700, Davide Libenzi wrote:
But that code *never* returns WANT_READ/WANT_WRITE. Non blocking sockets
always get SSL_ERROR_SYSCALL. Well, unless the case where they both
succeed immediately - but that's like blocking behaviour.
Yes, I'm well aware of
On Sat, 29 Sep 2007, Thor Lancelot Simon wrote:
As far as changes to the existing behaviour, blocking BIOs will never get
the new error code (0). And noone could have used the non-blocking BIOs
in a sane way, with the current behavior
(lack of proper WANT_READ/WANT_WRITE).
I'm sorry,
On Sat, Sep 29, 2007 at 03:11:18PM -0700, Davide Libenzi wrote:
Heh? Wait for readwrite? Consider such code:
for (;;) {
err = SSL_shutdown();
code = SSL_get_error(ssl, err);
if (code == SSL_ERROR_SYSCALL) {
Thor Simon wrote:
On Sat, Sep 29, 2007 at 03:11:18PM -0700, Davide Libenzi wrote:
Heh? Wait for readwrite? Consider such code:
for (;;) {
err = SSL_shutdown();
code = SSL_get_error(ssl, err);
if (code == SSL_ERROR_SYSCALL) {
On Sat, 29 Sep 2007, Thor Lancelot Simon wrote:
On Sat, Sep 29, 2007 at 03:11:18PM -0700, Davide Libenzi wrote:
Heh? Wait for readwrite? Consider such code:
for (;;) {
err = SSL_shutdown();
code = SSL_get_error(ssl, err);
if (code ==
On Sat, Sep 29, 2007 at 03:35:29PM -0700, Davide Libenzi wrote:
I seriously doubt ppl are using SSL_shutdown() with non-blocking BIOs,
together with the current API semantics. Seriously.
Well, how do you suppose they're terminating their SSL sessions? If you
look at the archive of this
On Sat, 29 Sep 2007, Thor Lancelot Simon wrote:
On Sat, Sep 29, 2007 at 03:35:29PM -0700, Davide Libenzi wrote:
I seriously doubt ppl are using SSL_shutdown() with non-blocking BIOs,
together with the current API semantics. Seriously.
Well, how do you suppose they're terminating their
I seriously doubt ppl are using SSL_shutdown() with non-blocking BIOs,
together with the current API semantics. Seriously.
Are you new here? This library has been around for more than a decade.
There are *lots* of people using the current API with non-blocking.
Seriously.
double/triple
On Sat, 29 Sep 2007, Richard Salz wrote:
I seriously doubt ppl are using SSL_shutdown() with non-blocking BIOs,
together with the current API semantics. Seriously.
Are you new here? This library has been around for more than a decade.
There are *lots* of people using the current API
Define elegantly.
The current API works. Better is not a reason to change it.
/r$
--
STSM, DataPower Chief Programmer
Websphere DataPower SOA Appliances
http://www.ibm.com/software/integration/datapower/
__
OpenSSL
37 matches
Mail list logo
