This is starting to look like an ssl bug, either in OpenSSL or the SSL on the
securityfocus server. I think it's shown up by the following change in
transfer.c:

===================================================================
RCS file: /cvsroot/curl/curl/lib/transfer.c,v
retrieving revision 1.110
retrieving revision 1.111
diff -c -r1.110 -r1.111
*** curl/curl/lib/transfer.c 2002/09/13 12:40:36 1.110
--- curl/curl/lib/transfer.c 2002/09/16 14:02:08 1.111
***************

...snip...

*** 291,299 ****
                data->state.headerbuff = newbuff;
                k->hbufp = data->state.headerbuff + hbufp_index;
              }
! strcpy (k->hbufp, k->str);
! k->hbufp += str_length;
! k->hbuflen += str_length;
              if (!k->headerline && (k->hbuflen>5)) {
                /* make a first check that this looks like a HTTP header */
                if(!strnequal(data->state.headerbuff, "HTTP/", 5)) {
--- 286,294 ----
                data->state.headerbuff = newbuff;
                k->hbufp = data->state.headerbuff + hbufp_index;
              }
! memcpy(k->hbufp, k->str, nread);
! k->hbufp += nread;
! k->hbuflen += nread;
              if (!k->headerline && (k->hbuflen>5)) {
                /* make a first check that this looks like a HTTP header */
                if(!strnequal(data->state.headerbuff, "HTTP/", 5)) {

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.

This change, from using strcpy to memcpy, allows the trailing nulls in k->str
to be copied into the output, whereas in previous versions, of libcurl they
would have been truncated/ignored.

Looking in Curl_read (sendf.c:333), this data is exactly as returned by the
underlying SSL_read function:

    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.

The workaround is to change back to the strcpy, instead of the memcpy (which
is basically what you are doing, Craig), but that's only a kludge which works
because headers cannot contain binary data. If there's some underlying
problem with SSL_read, it's potentially going to clobber binary body data as
well. I think this has to be triggered by some specific server-side
behaviour (bug? No, never!) in the specific version of IIS in use, otherwise
we'd surely have noticed curl corrupting SSL body data before now!

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!).

Cris

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Received on 2002-10-09