Hi, I get 'Internal Error 500' for the first message that goes from Siebel to Datapower, after a Siebel server restart. The Siebel logs looks fine. Datapower is not able to give detailed logs. Also they see two transactions from Siebel during the failure case. So we were left with no option other than to check network trace. I need your help to understand from network logs on what is happening in the failure case. Also need your help to decrypt application data and HTTP post frame. FYI: We are using digital certificates. Uploaded failure cap file screenshot: http://www.4shared.com/photo/aXEzzgcR/Success_case.html Thanks asked 09 Oct '13, 02:41 siebeleai edited 09 Oct '13, 02:54 |
3 Answers:
O.K. unless you have the private key for that certificate (should be on the Datapower server), you cannot decrypt the SSL/TLS session and thus you cannot check for possible error messages (and requests) in HTTP.
Internal Error 500 is usually caused by a problem on the server itself (Datapower), because it was unable to serve the request. There are many reason for this kind of problem, most of them are related to the server and not the client. It think the error could also be caused by a wrong HTTP request, although I can't show an example for this. So, you actually need access the clear text (decrypted) HTTP communication. For decryption you need the private keys of the server (Datapower - ask the admin where to find them). If you don't have or get access to the private key, you cannot decrypt the SSL/TLS communication and thus your options are limited to logs, as I don't think you can use any SSL/TLS intercepting tools (burp suite, Fiddler2) in such an environment. Please read/watch these, how to decrypt an SSL/TLS session.
++ UPDATE ++ Apparently (according to the comments) it is hard to decrypt the SSL/TLS traffic. I suspect, that the SSL/TLS handshake is not fully captured. Anyway, if decryption does not work for you, you could try to use 'SSL offloading' via stunnel. That way, you can capture the clear text communication between Siebel and Datapower. Here is how it works
If you cannot run stunnel on the Siebel server itslef, no problem. Just run it on a dedicated server
In either case you need to change the Siebel configuration and direct it to localhost:4433 or stunnel_server:443 instead of Datapower:443! Now, you can capture on localhost:10443 (loopback interface) and you will see the clear text communication between Siebel and Datapower.
Here comes the stunnel configuration (/etc/stunnel/stunnel.conf on Ubuntu). To install stunnel on Ubuntu run
File: /etc/stunnel/stunnel.conf
To create the cert and key (intercept.key.pem and intercept.cert.pem), you can use the following script.
Regards answered 09 Oct ‘13, 13:45 Kurt Knochner ♦ edited 16 Oct ‘13, 07:54 Thanks for your quick response. We already have the private key and I have configured wireshark to use the private key. But after I apply it, only few frames get decrypted, others doesn’t. If you were able to see the screenshot I uploaded, I could see frames like - ‘Client Hello’ ‘Server Hello’, ‘Certificate’ after I applied the private key. But,frames 8 -15 still remains decrypted, which I suppose may be the HTTP Post transactions. I need to see the HTTP frame as datapower team says that they are getting some duplicate HTTP Request fields, because of which this issue may be happening. As per datapower they are seeing duplicate HTTP header fields like below:
PLease advice. (10 Oct ‘13, 05:11) siebeleai
You need to capture every SSL session from the start (key exchange), otherwise Wireshark will not be able to calculate/extract the session key. If the other connections use already established SSL session keys, you cannot decrypt then. (10 Oct ‘13, 05:26) Kurt Knochner ♦ BTW: Headers with more that one value are not a violation of the HTTP RFC. If however the Datapower server accepts them or not, especially the SOAPAction header (non-standard), is a different story. BTW: The missing colon (:) after the header name is just a typo or copy-paste error, right? (10 Oct ‘13, 05:42) Kurt Knochner ♦ Thanks for the response. How can we ensure that all SSl session are captured? What we did is as follows: 1. Restarted Siebel server 2. Asked network Admin to capture trace 3. Sent one transactions (failed case) 4. Network Admin stores that as failed_test.cap 5. I triggered on more transaction (success case) 6. Network Admin captures and stores that as success_test.cap Also how do we know which session key is used? Appreciate your help (10 Oct ‘13, 06:58) siebeleai
By starting the capture early enough ;-). Maybe start the network capture first then restart the server !? But even then, if the client (Siebel) uses TLS Session tickets, it may get tricky. (10 Oct ‘13, 07:21) Kurt Knochner ♦ I am not sure of TLS Session ticket. How can we check this? But one thing I am sure.. we have done these tests quiet a number of times, so we should be having sessions from the start. (10 Oct ‘13, 23:37) siebeleai
The following filter should trigger on session tickets (available since Wireshark 1.8.0).
(11 Oct ‘13, 01:15) Kurt Knochner ♦ I could not find anything with ‘ssl.handshake.session_ticket’. But there was 1 packet when searched with ‘ssl.handshake.session_id’, which had a session Id. (15 Oct ‘13, 03:31) siebeleai
A session ID is part of the SSL handshake and can be used for later resumption of the connection, so I wonder why you see only one packet with a session ID !??! So, you should see much more frames with a Session ID during the handshake. That might explain why you cannot decrypt the packets. Either you did not capture the full handshake or your SSL client (somehow) reuses SSL Session IDs even after a restart, which would be kind of strange, as it would have to save the whole SSL session internals (keying material etc.). I don’t think the later is the case, and thus I conclude: You did not capture the whole SSL/TLS handshake. Can you post a sample capture file somewhere (google docs, dropbox, cloudshark) and/or a SSL decrypt debug file? (15 Oct ‘13, 07:32) Kurt Knochner ♦ (16 Oct ‘13, 04:01) siebeleai I’m not allowed to access the file! BTW: see the ++ UPDATE ++ in my answer. (16 Oct ‘13, 07:52) Kurt Knochner ♦ Can you try now, I have changed the access rights: https://docs.google.com/file/d/0Bzt9LsITOQKJQldvUXdqU2p0U2c/edit?usp=sharing (16 Oct ‘13, 22:56) siebeleai
That’s usually a sign for the wrong key. Are you sure you’ve taken the right key from the server? You add keys for port 41166 and port 5665. Maybe your Datapower server uses a different cert (+key) for those ports! BTW: Did you try the stunnel method I mentioned in the answer UPDATE? (17 Oct ‘13, 01:43) Kurt Knochner ♦ showing 5 of 13 show 8 more comments |
If you get an "Internal Error 500" from the Datapower server, you will not learn much more from a network trace, unless some requests generate the 500 response and others generate a 200 OK response. You need to debug on the Datapower server to determine the cause of the Internal Server Error. As for decrypting SSL traffic, you will need to point wireshark to a file with the private key as is configured on the Datapower server. Have a look at http://wiki.wireshark.org/SSL and http://sharkfest.wireshark.org/sharkfest.09/AU2_Blok_SSL_Troubleshooting_with_Wireshark_and_Tshark.pps answered 09 Oct '13, 13:49 SYN-bit ♦♦ Thanks for your quick response.. As per datapower team they are getting some duplicate HTTP Request header fields, because of which they say this issue may happen, though they are not sure. So to rule out the possibility we need check network logs, as in Siebel logs it does not show any duplicate HTTP headers. Datapower had sent a sceenshot that has duplicate HTTP header fields like below: User-Agent Mozilla/4.0,Mozilla/4.0 Accept text/,text/ SOAPAction "http://ci.marriott.com/ws/v1/CreateQuote/","http://ci.marriott.com/ws/v1/CreateQuote/" Please advice. (10 Oct '13, 05:15) siebeleai |
I don't know if you managed to decrypt the trace. However if you are working from a browser an easier way to see what is going on at http level is to use fiddler. Fiddler intercepts your browser traffic and maintains the ssl connection with the server. Things like sending a duplicate header might be explained by this. answered 15 Oct '13, 11:34 easterman But Fiddler can be used only on Windows platform right? Our Siebel server is on Linux OS. However client browsers are on windows.. Can Fiddler be installed on my client machine and configured to to capture the webservice request and response? (15 Oct '13, 21:41) siebeleai Fiddler is a proxy than can intercept SSL/TLS. So, it is good for client requests as you can configure your browser to use a proxy. It might also be used for communication between your Siebel server and the Datapower backend. However your Siebel server then needs to use a proxy when communicating to the Datapower server. If that is possible, I don't know. I guess your Siebel gurus should be able to tell you. But I'm not sure if it is a good idea to proxy the whole backend communication (Siebel -> Datapower) through Fiddler. Fiddler was built with client troubleshooting in mind and not network troubleshooting. I guess that there might be "unwanted effects" (if it works at all), like overload, missing requests etc. due to Fiddlers inability to handle a large request load. (16 Oct '13, 03:15) Kurt Knochner ♦ Hello, the answer is already given above. Fiddler is windows indeed. Using firefox you can even use it as a plugin. One thing you must do is enable ssl intercept in the configuration. I think using it as a proxy gets for datapower istoo complicated and the main reason here to use fiddler instead of wireshark is that decrypting ssl traffic is possible but more complicated. so just use it at your client. As your problem is now described as getting duplicate http headers I think fiddler will give enough information because it gives you the whole http conversation. One other thought, I was suprised how easy you got the private key. Since they are so cooperative, another option would be to let the server switch to plain http instead of ssl fot testing. This way you don't have to decrypt the traffic. (16 Oct '13, 04:06) easterman
well, the problem is between Siebel servers and Datapower server. It's (most certainly) not a client problem, so using Fiddler at the client does not really help. (16 Oct '13, 04:27) Kurt Knochner ♦ You're probably right. I had (and have) no idea what a Siebel server does. So unless it acts as a proxy for client requests Fiddler will be no use. Quick look suggests it works as a webserver which interacts with a datapower host. So no quick solution by using fiddler. So decrypt or switch to plain http traffic for analysis. (16 Oct '13, 05:36) easterman
But stunnel will help. See the ++ UPDATE ++ in my answer. (16 Oct '13, 07:10) Kurt Knochner ♦ showing 5 of 6 show 1 more comments |
Any chance that the HTTP response does not include a
Content-Length
field? Without this, Wireshark will not provide a dissection.