> From: owner-openssl-us...@openssl.org On Behalf Of Raj
> Sent: Wednesday, 15 September, 2010 09:15
> Can anybody tell me how to read the chunked data using Open SSL API,
This is really an HTTP question, not an SSL question. You are just
using SSL as transport, and would face the same issues with TCP.
However, I have no idea where HTTP questions are on-topic.
> I am writing a Man In The Middle application which intercepts
> the browser request and sends own request to the server , read
> the information from the server and puts it back to the browser.
> Now I am some what blocked in point where I need to read the
> Chunked Data from the server
> I have used the Open SSL function SSL_read in a loop which
> works until it get 0 length chunked data, But some time I am not
> getting 0 sized data. Is there anything else to do. I am pasting
> my code snippet below
> do
> {
> memset(pcBuff,'\0',iBufferSize); // Initializes the char * to
null value
> dwReadDataLen = SSL_read(pServerssl,pcBuff,iBufferSize); // Read
data from the Server
> if(dwReadDataLen == 0 || dwReadDataLen == SOCKET_ERROR)
> break;
Aside: Winsock SOCKET_ERROR happens to be -1, which is what OpenSSL
(SSL_read and many others) uses for error, but AFAIK there is no
guarantee of this. I think it's better to use -1, or just <= 0.
> SSL_write(pBrowserssl,pcBuff,dwReadDataLen); // Write back to the
browser
> if(GetChunkedSize(pcBuff) == 0) // This function checks
> whether the last characters = \n\r and if found it retrieves the value
> break;
> } while(true);
I guess you mean the last characters in this bufferful of data are
last=\n nexttolast=\r and before that is something formatted as a
chunk-size (generally) or a last-chunk (specifically)?
I'd say most likely bet is that the server is using trailer
and you didn't allow for it, or not correctly.
In principle there's no guarantee that a chunk mark, nonlast or last,
occurs within a transport buffer, but it is quite likely especially
for last. If you use pipelining, there's no guarantee that last-chunk
for reply 1 isn't followed in the same transport buffer by beginning
of reply 2, but if you are using pipelining you should know about it.
Conversely, depending on your server(s) and application(s) it's
entirely possible for data landing at the end of a transport buffer
to look like a last-chunk (or a nonlast chunk-size) when it isn't.
If you simply trust what it looks like and your clients are using
servers that have user provided content, like any kind of social
network, this would allow an attacker to falsify a response header
-- after an error that a client could detect, but the trend in
browsers at least seems to be to silently ignore and retry and
"correct" errors rather than giving the user any information.
I don't see offhand how an attacker could leverage this, but
experience has shown attackers can be amazingly twisty-minded.
I don't think there's any way to do chunked safely without
actually tracking the protocol state, which is a pain, which
is why in my case I just don't support it. Good luck.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
