On Mon, Nov 01, 1999 at 09:15:23AM +0100, [EMAIL PROTECTED] wrote:
> On Sun, Oct 31, 1999, [EMAIL PROTECTED] wrote:
> >
> > I've since recompiled everything with complete debug info, and gotten
> > a stack-backtrace:
> >
> > #0 RSA_private_decrypt (flen=64, from=0x812aaa8
> > "G�q]k\2009\206U�)\n�\027e��X\002�8о��\nQ \tQ\017�<���g�A�$N#\226��ج��8�\224
> > {\2276a^d�\037V�V�*�\023",
> > to=0x812aaa8 ".....", rsa=0x810ae58, padding=1)
> > at rsa_lib.c:228
> > #1 0x402d9c9d in ssl3_get_client_key_exchange (s=0x8128418) at s3_srvr.c:1240
>
> Yeah, that's definetely the same segfault someone other has also seen. It's
> inside OpenSSL and seems to be not directly related to the session cache, I
> think. Instead I've seen such problems inside OpenSSL one year ago under
> Solaris if DSO was used. Are you using the DSO facility for building the
> modules?
Yup - I'm using the DSO facility. I would hate to have to give this up as
it's tremendously useful.
Here's a bit more information I've uncovered so far:
- apache will still serve up ssl connections to _some_ users once it gets into this
segfault loop state. I haven't quite figured it out yet, but it appears to
only allow ssl connections to a user who has previously connected before it had
problems. It's not based on ip address, because from behind a masquerading
firewall, I can connect with Netscape on Linux just fine, but if I switch to
using Netscape under windows, apache segfaults (I primarily use Linux, so that
would have been what was used for the original access). This only started
happening once I switched to the MM session cache. Before that, it would
segfault for everybody.
- Doing a restart does _not_ fix the problem. I have to do a complete stop
and cold start (apachectl stop; apachectl startssl)
<snip>
> The problem is that this is very deep inside OpenSSL and the last code in
> mod_ssl was the one which called SSL_accept(). Between this mod_ssl->OpenSSL
> step and the segfault a lot of stuff happens inside OpenSSL. So it's not very
> easy to find the reason for the messed up RSA structure. Hmmm... I think one
> has to trace the whole SSL handshake to find the reason. The only thing I can
> offer you here is that if you provide me with a temporary "rse" account and a
> step-by-step list which shows how to reproduce the segfault, I can try to step
> through the code and find out a little bit more.
I'm not sure I'll be able to set that up, but I can try. In the meantime, if you
like I can script a step by step trace of the whole mess from SSL_accept the next
time it happens. Hmm... is there a gdb script I can use that will step through
code automatically and print out all local variables at each level? If not,
let me know if there are some choice structures in the path that I can get info
on for you.
Unfortunately, I can't predict when this happens - so far the earliest it's
happened is after an overnight idle period. Some times it's gone as long
as 2 or 3 days without doing it. However, when it does do it, it's easy to
reproduce - all ssl connections are denied :-/ The tricky part is trying to
catch the right apache process that's going to get the next request...
Thank you
--
David Kerry ([EMAIL PROTECTED])
Stable Network Technologies Inc. (www.snti.com)
Toronto, Ontario, Canada
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
