Re: Oops - Serious bug in 7.10 - more info
Date: Wed, 9 Oct 2002 22:31:05 +1000
Oops, my bad. I think I pointed the finger at ssl prematurely (read on):
On Wed, 9 Oct 2002 21:49, Daniel Stenberg wrote:
> What OpenSSL versions are you guys using for this? I have an oldish 0.9.6c
> and it shows this problem.
I tried 0.9.6c and 0.9.6g - same. I don't think it is openssl after all.
> > Debugging, 'nread' (for the first SSL 'packet' from
> > analyzer.securityfocus.com) is '122', but the printable text in the first
> > packet is much shorter, only 44 bytes (ending at "-Type: text"). The rest
> > are NULL.
I was wrong - my debuger (ddd) 'helpfully' shortened it's display of the
variable to show the start and end of the string, replacing the middle part
with '...' - I counted it as 44 chars. It's not, it's correct at 122 bytes.
The mangling must be occuring in transfer.c.
I think it's a lower case 'argh' now...
> > nread = SSL_read(conn->ssl.handle, buf, buffersize);
> > Breaking here, we can see that nread is 122, but buf has only 44
> > printable chars, so it looks like openssl's problem, not libcurls.
so it's back to looking at transfer.c, sorry.
> This change was necessary to handle the odd cases when the remote server
> doesn't reply a single header, but instead starts with a binary chunk. It
> is a violation of the HTTP spec, but a violation we can deal with and that
> browsers deal with, so I think we should.
> Right, the work-around to put the strcpy() back will work for all
> well-behaving HTTP replies.
> > I'll see if I can get other ssl tools (or sslsniff) to show the same
> > behaviour with that server (and I'll check the openssl changelogs as
> > well!).
I couldn't repeat this with any combination of openssl or stunnel. under
0.9.6c or 0.9.6g, for the same site.
Sorry for the confusion... I'll dig in transfer.c and see if I can see whats
wrong, but it's pretty late in my timezone...
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
Received on 2002-10-09