We also experienced similar problems with AOLserver and nsopenssl 3.x,
I've
been meaning to investigate farther.
For us, nsopenssl would go into an infinite loop. I was never able to
trigger it myself, but it happened on a fairly regular basis. The
culprit
seemed to be OpenSSLProc in nsopenssl.c.
The call to
n = NsOpenSSLConnOp(sslconn->ssl, bufs->iov_base, (int) bufs->iov_len,
NSOPENSSL_SEND);
had bufs->iov_len == 0. This would result in SSL_write being called
with 0
bytes, and according to the OpenSSL documentation, the behavior of
that is
undefined. (And because of the error, nsopenssl would try again, ...)
I
just added a check that returned -1 before calling NsOpenSSLConnOp if
(int)
bufs->iov_len == 0. I don't know the nsopenssl code well enough to
say if
that is a correct fix, but it did seem to make the problem go away.
On at
least a couple of occasions it happened around the same time as a call
to
our tcllib-based sendmail, but that could be completely coincidental.
We've also recently noticed a separate problem that causes nsopenssl to
crash. The last time this happened was the first time we attached a
debugger, the problem was with IssueTmpRSAKey in sslcontext.c.
Ns_Log(Notice, "%s (%s): Generated %d-bit temporary RSA key",
MODULE, sslconn->ssldriver->server, keylen);
When this got called, sslconn->ssldriver was NULL, so trying to access
the
server field crashed nsopenssl, I'm not sure if the earlier crashes
were the
same thing. I downloaded some old export versions of netscape since
the
comments for IssueTmpRSAKey suggest it is only used for 40-bit
browsers, but
so far these ancient builds haven't wanted to install on my machine.
Jamie
On Wed, 21 Jul 2004 10:50:37 -0400, Janine Sisk <[EMAIL PROTECTED]>
wrote:
On Jul 21, 2004, at 10:24 AM, Dossy wrote:
On 2004.07.21, Janine Sisk <[EMAIL PROTECTED]> wrote:
Ok... any suggestions? I'll see if I can reproduce the error.
If you can reproduce the error, I will definitely make time to look
into
it.
I was able to reproduce it, but only loosely - shortly after placing
an
order the errors began to spew forth. Not immediately, which I found
odd; I finished the transaction, checked the log, found nothing, went
to get a cup of coffee and came back to errors galore. But I was able
to see the same loose correlation between other orders being placed
and
a slew of errors showing up.
The certificate should work with nsopenssl 2.1a with AOLserver 3.x,
though.
Yes, I realized that afterwards and that's exactly what I've done. No
errors so far.
Unfortunately, I think this will be very difficult to work on because
it probably has something to do with our use of the ancient cybercash
module. The history here is that this client was using Cybercash when
they were taken over by Verisign, and so they were allowed to keep
using the old Cybercash interface. This opens a socket and talks
directly to the Cybercash servers. In order to repro the problem I
think you would have to have access to a site that did this, and I
can't leave the site in this state since it's a real production
machine. This morning, before I switched back to 3.3, it managed to
bring the error log back up to 2 Gb in a matter of minutes. Most
impressive! :) In order to let you do the work on this site I'd have
to arrange with the client to have a window of time where we blocked
users from the site; he might go for that, but it would be a hassle
for all.
These are all debug messages, and since everything seemed to be
actually working it might be possible to "fix" the problem by just
turning those off. But without understanding more than I currently do
about how it all works, I'd feel a little funny doing that.
The odd thing is that AFAIK that Cybercash module does not use any SSL
code. I know it doesn't use https; the comments in the code make that
very clear. So the whole thing seems rather odd to me. Of course I
can't be sure it's even related to the Cybercash module, but since I'm
the only one using it and the only one reporting this, it walks like a
duck...
Unfortunately, if we can't fix this then the only option is to
eventually make the client change card processors. Although it's a
huge hassle it's something they may have to do eventually anyway;
Verisign may not support the old Cybercash interface forever, and we
can't use their newer PayflowPro stuff (reports that they've done
something to it which causes it to crash AOLserver and they don't care
a whit). But I would rather have the cause be because Verisign
forced
the issue and not because of a technical problem I could not solve!
thanks,
janine
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the
Subject: field of your email blank.
