Hi
Thanks for your valuable suggestion. I didn't understand some points
which you described in the previous posting, may because of my lack of
exposure to the socket technology.
I have tried one more method to read the data from the socket, which was
partially successful it is defined as follows
do
{
dwReadDataLen = SSL_read(Serverssl,pBuff,iBufferSize); // Gets the
data from the server side
SSL_write(SourceSsl,pBuff,dwReadDataLen); // Writes the data back to
the SSL
} while(dwReadDataLen > 0 );
By using this method I am able to read the content data from the server and
put it back to my browser. But this method is not consistent though,
Sometimes browse request will not get completed and also it takes lot of
time complete one browse request
-------------------------
Replies and quires to the previous posting
For a socket used with openssl directly, I believe OVERLAPPED
will be ignored and is of no use. I think you would have to do
your own 'physical' level either as your own BIO type or as
a BIO_pair looping back to your code (the more usual way).
Frankly I don't think you're anywhere near ready for that.
I didn't understand about this, Can you describe this in more detail, Sorry
for that I am new to this technology
You should check for error (<=0) and report/handle it. Error on _write
especially initial is not common, but if it ever happens, proceeding
with other operations will likely cause much greater confusion.
I have checked all the error codes of SSL functions in my application, I
have posted only some code snippet to avoid junk data
SSL_accept(Serverssl);
This is useless. SSL_accept _creates_ a server-side endpoint;
it is not applicable to a client-side endpoint.
I have removed this from my application
Also, the data read by SSL_read (like POSIX read or C fread)
does not get a null terminator byte added, so outputting
pBuff as a C-style string is likely to append garbage,
especially on the second or more time through the loop.
I have outputted the buffer only for indicative purpose. I have removed the
code for outputting the buffer
That's your problem. SSL_pending only indicates data _already
received and buffered_ by OpenSSL but not yet read by the app.
For responses more than one SSL record (max 32kbytes if I recall
correctly, and server may choose less) AND (probably) more than
the TCP window (varies but typically 2 MTU = about 3kbytes to start)
there will be some time delay between receiving the first chunk
of the data and the next, and the next and so on.
} while(SSL_pending(Serverssl));
Instead of using the above condition I have opted for
while(dwReadDataLen > 0 );
By using this I was able to read the content data.
For a waited/blocking socket, which is the default as you have here,
you need to keep reading from the server (and in your case writing
back to the client) until you've done all the data in the response.
If you require, or the server chooses, HTTP/1.0 style conn-per-txn
(also known as connection: close or not-keepalive or not-pipelined,
and also not-chunked) you can just loop until you receive "EOF" (0)
from SSL_read, caused by the server closing the connection.
"EOF" (0)
I am not sure about EOF(0), is that some thing similar to End Of File in
C++;
If you allow and the server uses HTTP/1.1 keep-alive (or pipelining)
and/or chunked data, the situation can get quite a bit more
complicated. See RFC 2616.
If you use a nonblocking socket (which is supported on Windows
as far as I know but is apparently not the same as OVERLAPPED)
you can also do your own timeout -- that is, read until EOF
or optionally calculated end of the response body, *or* timeout.
Since HTTP servers will normally send a complete response within
a short time (like at most a few seconds), and if one doesn't
a person at a browser usually doesn't want to wait anyway,
this can be a good simple compromise.
Could you send me some code snippet using 'bio' in SSL, I have seen using
'bio' is some sample applications instead of Sockets
Thanks,
Raj
Rajmohan SK
----- Original Message -----
From: "Dave Thompson" <dthomp...@prinpay.com>
To: <openssl-users@openssl.org>
Sent: Saturday, August 07, 2010 9:06 AM
Subject: RE: Man in the middle proxy - Not working
From: owner-openssl-us...@openssl.org On Behalf Of Raj
Sent: Friday, 06 August, 2010 10:14
I was able to read the content data from the server
using SSL_read
and put back to the browser by using SSL_write. I don't know
whether is a
right approach or not.
If you are doing an SSL connection to the server then
SSL_write to and SSL_read from the server are correct.
(And you should since the client is requesting SSL.)
SSL_read from and SSL_write back to the client are
correct if the client is SSL, and you said it is.
For [an .ico] I got the response as follows and I was
able to see the
icon in my browser <snip>
But for [a .png], which is 42,565 bytes long, I am
receiving the
following output. I understood that there is more to do
inorder to read the
content data, which I am not sure about <snip>
Can anybody tell me what else should I do inorder to read
the content
and show it the browser. The following are sending some code snippets
RequestSock =
WSASocket(AF_INET,SOCK_STREAM,0,NULL,0,WSA_FLAG_OVERLAPPED);
For a socket used with openssl directly, I believe OVERLAPPED
will be ignored and is of no use. I think you would have to do
your own 'physical' level either as your own BIO type or as
a BIO_pair looping back to your code (the more usual way).
Frankly I don't think you're anywhere near ready for that.
pHost = gethostbyname(pcTargetURL);
memset(&ClientAddr,0,sizeof(ClientAddr));
ClientAddr.sin_family = AF_INET;
memcpy(&ClientAddr.sin_addr,pHost->h_addr,
pHost->h_length);
ClientAddr.sin_port = htons(atoi(pcPort));
if(0 != connect(RequestSock,(SOCKADDR *)&ClientAddr,
sizeof(SOCKADDR_IN)))
{
closesocket(RequestSock); // Connection failed
return false;
}
SSL *Serverssl;
Serverssl = SSL_new(m_pSSLCtx);
SSL_set_fd(Serverssl, RequestSock);
iRes = SSL_connect(Serverssl);
if(iRes <= 0 )
{
ERR_print_errors_fp(stderr);
cout << " connect Failed " << endl;
}
iRes = SSL_write(Serverssl,pcData, strlen(pcData));
You should check for error (<=0) and report/handle it. Error on _write
especially initial is not common, but if it ever happens, proceeding
with other operations will likely cause much greater confusion.
SSL_accept(Serverssl);
This is useless. SSL_accept _creates_ a server-side endpoint;
it is not applicable to a client-side endpoint.
do
{
dwReadDataLen =
SSL_read(Serverssl,pBuff,iBufferSize);
SSL_write(SourceSsl,pBuff,dwReadDataLen);
cout << "Read buffer \n" << pBuff << endl;
Again check for errors. Especially on the _read side,
they are actually quite possible.
Also, the data read by SSL_read (like POSIX read or C fread)
does not get a null terminator byte added, so outputting
pBuff as a C-style string is likely to append garbage,
especially on the second or more time through the loop.
} while(SSL_pending(Serverssl));
That's your problem. SSL_pending only indicates data _already
received and buffered_ by OpenSSL but not yet read by the app.
For responses more than one SSL record (max 32kbytes if I recall
correctly, and server may choose less) AND (probably) more than
the TCP window (varies but typically 2 MTU = about 3kbytes to start)
there will be some time delay between receiving the first chunk
of the data and the next, and the next and so on.
For a waited/blocking socket, which is the default as you have here,
you need to keep reading from the server (and in your case writing
back to the client) until you've done all the data in the response.
If you require, or the server chooses, HTTP/1.0 style conn-per-txn
(also known as connection: close or not-keepalive or not-pipelined,
and also not-chunked) you can just loop until you receive "EOF" (0)
from SSL_read, caused by the server closing the connection.
If you allow and the server uses HTTP/1.1 keep-alive (or pipelining)
and/or chunked data, the situation can get quite a bit more
complicated. See RFC 2616.
If you use a nonblocking socket (which is supported on Windows
as far as I know but is apparently not the same as OVERLAPPED)
you can also do your own timeout -- that is, read until EOF
or optionally calculated end of the response body, *or* timeout.
Since HTTP servers will normally send a complete response within
a short time (like at most a few seconds), and if one doesn't
a person at a browser usually doesn't want to wait anyway,
this can be a good simple compromise.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
