Hi. I am troubleshooting an SSL transaction that goes through a web proxy server, and I am only able to capture packets at the Client end. In this scenario, the Client uses an HTTP CONNECT to create an SSL Tunnel through the proxy server to the destination server (aka "Origin Server"). In my situation, the tunnel is created successfully, and the SSL Handshake is completed successfully, but when the Client actually sends "application data" to the Origin Server, it does not get any response, and finally the Client receives a FIN, and the connection is closed. My question is this... The application data packets sent by the client - after the SSL Handshake completes - all receive TCP ACK's. Does that indicate that the Origin Server has ACK'd those packets? Or, simply that the proxy server has ACK'd those packets? In other words, can I use the fact that these packets are ACK'd to conclude that the Origin Server definitely received the Client's request? Or, is it possible that the proxy server ACK'd the packets, but never received an ACK from the Origin Server, or, worse yet, never SENT the packets to the Origin Server? Thx, Feenyman99 asked 14 Nov '10, 02:36  feenyman99 |
One Answer:
I guess that all depends on the proxy you are using. If it's a proxy that does SSL inspection (by dynamically creating certificates and having the proxy-root-ca on all clients), then it's an application layer proxy which means all communication is between the client and the proxy, independently from the communication between the proxy and the origin server. However, I think most proxies are just TCP (socks) proxies when it comes to "CONNECT". Which I would guess means that all TCP packets are just natted, but other than that not altered. The only way to know for your particular brand of proxy is to either make a trace on both sides or ask the vendor how it processes data, but even then I would still want to double check by looking at the traces on both sides of the proxy. answered 14 Nov '10, 05:04  SYN-bit ♦♦ |
Thx SYNbit! After I posted this question, I began to realize that getting a trace from the proxy server is the only sure way to get a definitive answer. It will take some doing, but I will push through my corporation's bureaucracy to get that done, and post the results here - hopefully within a week.
Most corporate proxies that I know will not decrypt SSL. There's too much liability involved (imagine if my company decrypted my access to Chase bank and it got leaked somehow?). So it's entirely possible that you're just getting a tcp proxy. One other clue might be by looking at the IP TTL. Keep an eye on the IP TTL to see what the proxy uses by default. So ping the proxy and see what the IP TTL looks like. Then look at your internet traffic (Origin server) and see what the IP TTL looks like.