RE: getting SSL_ERROR_ZERO_RETURN when calling operation from WSDL using axis2c
From: dthomp...@prinpay.com To: openssl-users@openssl.org Subject: RE: getting SSL_ERROR_ZERO_RETURN when calling operation from WSDL using axis2c Date: Mon, 6 Feb 2012 20:43:28 -0500 From: owner-openssl-us...@openssl.org On Behalf Of manoj dhyani Sent: Saturday, 04 February, 2012 23:59 both soapUI and client application built using axis 2c are running on the same machine, I have axis2java based client running on the same machine and works fine the request is hot very big, the webserver requires WS-Security username and password, but if you don't pass that it returns a soap fault in case of SopUI and axis2java but fails with the same error for axis2c the buffer in axis2c is null, I do see encrypted alter and connection reset after FIN I am attaching the wireashark capture both when the call is done from SoapUI and Axis2c client Okay, in the good case (SoapUI) after handshake (resulting in TLS1.0 RSA-RC4-128-SHA) we have: #17 send enc-data 559-20=539 #18,19 recv enc-data 1471-20=1451 #21 recv enc-data 69-20=49 #22 send enc-data 762-20=742 about .4sec delay to #23 ACK and another .4sec to #24,25,27,28,30,31,33,34,36 recv enc-data 12218-20=12198 539 is about right to be HTTPhdr plus a smallish request; 1451 + 49 could be a segmented response (but see next) or a response with some HTTP control like chunked encoding. 742 could be a slightly larger request and 12198 a big response (not segmented, but maybe from a different part of server). In the bad case (app+axis2) there's 4.5sec delay starting handshake which I'll hope was just debugging, then after handshake we have: #15 send enc-data 204-20=184 #16 send enc-data 22-20=2 #17 send enc-data 944-20=924 about .2sec delay maybe Nagle then recv ACK(#16) and ACK(#17) then #20 recv enc-alert with piggyback FIN (with PSH ACK) #21 send ACK(#20+FIN) not FIN (probably in stack) #22 recv RST (with ACK and good ack/seq) The server apparently dislikes your request and closes aggressively: it RSTs to your machine's ACK(FIN) even though it may still have seqctrs and (thus) endpoint block, and even though you haven't begun to FIN. This is not ideal TCP behavior, though it can be acceptable in an error case. It looks very odd that your request is sent as 184,2,924. 184 is enough for HTTPhdr but little or no request data. 2 is a very odd size to do in the middle. Total 1110 is noticeably more than 539 for first request in good case. Since you can debug, I would look at the calls to SSL_write, and verify that when concatenated they form a valid request (HTTPhdr then SOAP request body), and try to look at the calling (axis2c) code to see why it's sending in pieces like this. Though in itself legal that behavior is somewhat unusual, and might be triggering a server limitation the other case doesn't. Hope this helps. Thanks ! yes, this helped the 2 bytes that you see in bad case is CRLF (carriage return and line feed), axis2c is sending this after sending the HTTP Header and before sending the Soap Request, but this is not causing any issue after debugging found that there is a difference in the way axis2c is sending the HOST parameter in the HTTP Header in case of axis2c it's adding the post number to the hostname Host: nestlepreview.i-nexus.com:443 where as in case of SoapUI only hostname is sent Host: nestlepreview.i-nexus.com if I change the Axis2c code to not suffix port it works fine, not sure if this is Axis2c bug or server side issue, I don't see any issue with other HTTPS webservices using default port when invoked using Axis2c client app let me post this in Axis2c forum and see if there is any way to control this parameter, looking at the code I didn't see any thing __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: getting SSL_ERROR_ZERO_RETURN when calling operation from WSDL using axis2c
From: owner-openssl-us...@openssl.org On Behalf Of manoj dhyani Sent: Saturday, 04 February, 2012 23:59 both soapUI and client application built using axis 2c are running on the same machine, I have axis2java based client running on the same machine and works fine the request is hot very big, the webserver requires WS-Security username and password, but if you don't pass that it returns a soap fault in case of SopUI and axis2java but fails with the same error for axis2c the buffer in axis2c is null, I do see encrypted alter and connection reset after FIN I am attaching the wireashark capture both when the call is done from SoapUI and Axis2c client Okay, in the good case (SoapUI) after handshake (resulting in TLS1.0 RSA-RC4-128-SHA) we have: #17 send enc-data 559-20=539 #18,19 recv enc-data 1471-20=1451 #21 recv enc-data 69-20=49 #22 send enc-data 762-20=742 about .4sec delay to #23 ACK and another .4sec to #24,25,27,28,30,31,33,34,36 recv enc-data 12218-20=12198 539 is about right to be HTTPhdr plus a smallish request; 1451 + 49 could be a segmented response (but see next) or a response with some HTTP control like chunked encoding. 742 could be a slightly larger request and 12198 a big response (not segmented, but maybe from a different part of server). In the bad case (app+axis2) there's 4.5sec delay starting handshake which I'll hope was just debugging, then after handshake we have: #15 send enc-data 204-20=184 #16 send enc-data 22-20=2 #17 send enc-data 944-20=924 about .2sec delay maybe Nagle then recv ACK(#16) and ACK(#17) then #20 recv enc-alert with piggyback FIN (with PSH ACK) #21 send ACK(#20+FIN) not FIN (probably in stack) #22 recv RST (with ACK and good ack/seq) The server apparently dislikes your request and closes aggressively: it RSTs to your machine's ACK(FIN) even though it may still have seqctrs and (thus) endpoint block, and even though you haven't begun to FIN. This is not ideal TCP behavior, though it can be acceptable in an error case. It looks very odd that your request is sent as 184,2,924. 184 is enough for HTTPhdr but little or no request data. 2 is a very odd size to do in the middle. Total 1110 is noticeably more than 539 for first request in good case. Since you can debug, I would look at the calls to SSL_write, and verify that when concatenated they form a valid request (HTTPhdr then SOAP request body), and try to look at the calling (axis2c) code to see why it's sending in pieces like this. Though in itself legal that behavior is somewhat unusual, and might be triggering a server limitation the other case doesn't. Hope this helps. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: getting SSL_ERROR_ZERO_RETURN when calling operation from WSDL using axis2c
On 2/3/2012 6:13 AM, manoj dhyani wrote: I am using the following WSDL https://nestlepreview.i-nexus.com/nestlepreview/webservices/v1/nexus.wsdl and trying to get data using the operations from the WSDL, the webservice client is written in C using Axis2/c 1.5 with openSSL enabled openSSL version 0.0.8l That doesn't look like a real OpenSSL version number, please double check. the certificated is verified and instead of getting a response axis2c throws a timeout error on debugging axis2/c the SSL_read() call is failing with error SSL_ERROR_XERO_RETURN This *could* be a result of stopping your program in the debugger affecting the actual socket send/recv calls in a way not expected by OpenSSL and/or Axis2. So try running your test program outside the debugger. The same WSDL if used in SoapUI works fine or with any other Java based clients Sounds like the server is OK then. any idea how to debug this issue ? is this a server side problem or client, if other client works I am not sure if it's server side issue or network issue __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: getting SSL_ERROR_ZERO_RETURN when calling operation from WSDL using axis2c
the openSSL version is 0.9.8l, I also tried using 1.0.0f but same issue the application fails with same error whether run from debugger or outside debugger I tried using wireShark to trace the communication when run from SoapUI and when from my app but the data is encrypted and I don't have server's private key Date: Fri, 3 Feb 2012 13:43:00 +0100 From: jb-open...@wisemo.com To: openssl-users@openssl.org Subject: Re: getting SSL_ERROR_ZERO_RETURN when calling operation from WSDL using axis2c On 2/3/2012 6:13 AM, manoj dhyani wrote: I am using the following WSDL https://nestlepreview.i-nexus.com/nestlepreview/webservices/v1/nexus.wsdl and trying to get data using the operations from the WSDL, the webservice client is written in C using Axis2/c 1.5 with openSSL enabled openSSL version 0.0.8l That doesn't look like a real OpenSSL version number, please double check. the certificated is verified and instead of getting a response axis2c throws a timeout error on debugging axis2/c the SSL_read() call is failing with error SSL_ERROR_XERO_RETURN This *could* be a result of stopping your program in the debugger affecting the actual socket send/recv calls in a way not expected by OpenSSL and/or Axis2. So try running your test program outside the debugger. The same WSDL if used in SoapUI works fine or with any other Java based clients Sounds like the server is OK then. any idea how to debug this issue ? is this a server side problem or client, if other client works I am not sure if it's server side issue or network issue __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: getting SSL_ERROR_ZERO_RETURN when calling operation from WSDL using axis2c
From: owner-openssl-us...@openssl.org On Behalf Of manoj dhyani Sent: Friday, 03 February, 2012 00:13 I am using the following WSDL https://nestlepreview.i-nexus.com/nestlepreview/webservices/v1/nexus.wsdl and trying to get data using the operations from the WSDL, the webservice client is written in C using Axis2/c 1.5 with openSSL enabled openSSL version 0.0.8l corrected later to 0.9.8l also 1.0.0f the certificated is verified and instead of getting a response axis2c throws a timeout error on debugging axis2/c the SSL_read() call is failing with error SSL_ERROR_XERO_RETURN Do you mean *returning*? 0 returned from SSL_read() is NOT SSL_ERROR_ZERO_RETURN, only 0 from SSL_get_error() is. 0 from SSL_read() means more-or-less-normal end-of-data. (Like recv at the TCP level, or fread or read on a file.) Is this the first SSL_read(), or has Axis2/c already read some data and is trying for more? The same WSDL if used in SoapUI works fine or with any other Java based clients any idea how to debug this issue ? is this a server side problem or client, if other client works I am not sure if it's server side issue or network issue If other clients work, it's logical the error is likely in your client, although not absolutely certain -- there could be a problem elsewhere that your client (only) exposes. On the other hand, if the problem is in your client code (at WS level) and the underlying layers (Axis2/C and OpenSSL) are correct, I would expect/hope to see a SOAP-level error, not just end-of-data. You mention network; did you try other client(s) from your *same* machine, or at least your same network connection (routing etc)? Most network problems would show up during the TCP connection or the SSL handshake, but possibly if the SOAP-level data here is large (and I didn't read through the WSDL to try to figure out) it might trigger an error, and an error at network level could do (forced) FIN and thus (abnormal) end-of-data at SSL level. You note later that you can't decrypt a Wireshark trace without the server privatekey. You can still see the lengths and timing of records; after adjusting for MAC and possibly padding (but on a default poke at the server I got RSA-RC4-SHA which doesn't pad) is your client sending data that's reasonable size for an HTTP header and SOAP body? And receiving similarly? Are you receiving an encrypted alert just before FIN? If so, even without decrypting you can guess it's *probably* shutdown, which would mean either the server thinks it sent a complete/valid reply or it had some internal error, possibly provoked by your request somehow. And if there is any encrypted data received (that is, not encrypted handshake which is the Finished, nor encrypted alert) you should see it in Axis2/C's buffer(s) in the debugger. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
getting SSL_ERROR_ZERO_RETURN when calling operation from WSDL using axis2c
I am using the following WSDL https://nestlepreview.i-nexus.com/nestlepreview/webservices/v1/nexus.wsdl and trying to get data using the operations from the WSDL, the webservice client is written in C using Axis2/c 1.5 with openSSL enabled openSSL version 0.0.8l the certificated is verified and instead of getting a response axis2c throws a timeout error on debugging axis2/c the SSL_read() call is failing with error SSL_ERROR_XERO_RETURN The same WSDL if used in SoapUI works fine or with any other Java based clients any idea how to debug this issue ? is this a server side problem or client, if other client works I am not sure if it's server side issue or network issue
