What do i need to send to a proxy server (http or socks) that will tell me if it is connected to the host i specified it to connect to.
Neither proxy protocol provides that functionality. There is no way to query a proxy to see what server it is connected to, or whether it is a still connected to a server. If you tell it to connect to a server, then you have to assume it is always connected to that server as long as you have a valid connection with the proxy. If the proxy loses its connection to the server, then it needs to close the connection with your client.
Related
I'm implementing HTTP over TLS proxy server (sni-proxy) that make two socket connection:
Client to ProxyServer
ProxyServer to TargetServer
and transfer data between Client and TargetServer(TargetServer detected using server_name extension in ClientHello)
The problem is that the client doesn't close the connection after the response has been received and the proxy server waits for data to transfer and uses resources when the request has been done.
What is the best practice for implementing this project?
The client behavior is perfectly normal - HTTP keep alive inside the TLS connection or maybe even a Websocket connection. Given that the proxy does transparent forwarding of the encrypted traffic it is not possible to look at the HTTP traffic in order to determine exactly when the connection can be closed. A good approach is therefore to keep the connection open as long as the resources allow this and on resource shortage close the connections which were idle (no traffic) the longest time.
This is the question about HTTP CONNECT method.
I learned that after CONNECT request from client a TCP connection is established between proxy and remote server.
Then, at the step of SSL handshake, does the proxy evaluate and relay any http data from client up to at TCP level? So the data is not passed to application level of the proxy?
I understood that after SSL session establishment any data from client is encrypted and the proxy cannot read those. But how about the time before SSL session establishment, that is, SSL handshake step?
After the proxy has sent a successful response to the clients CONNECT request a normal proxy will forward all data between client and server without any changes. This includes the TLS handshake for HTTPS connections tunneled using CONNECT.
Note that there are proxies which do SSL interception (typically at firewalls). In this case the data are not blindly forwarded but the proxy will be an active man in the middle which means that the client does not receive the original certificate from the server and that the proxy will decrypt and maybe even modify the traffic between client and server.
The problem is this:
I decided to make a messenger/chat (VCL application) with callback on DataSnap technology (IDE Delphi XE6), has created a simple DataSnap server (tcp / ip + http) without the database, and thick client.
All works fine if the whole thing run on a local network (tcp / ip) or via the Internet (http).Problems arise when run over HTTP and the client machine has a HTTP proxy server, the client application can not connect to my DataSnap server application. Client application gets error "10061 connection refused"
or "Expected datasnap context in request http://[YourServerIP]:[YourPort]/datasnap/tunnel".
I tried to enter IP and port of the proxy server to params of component TSQLConnection.Driver params DSProxyHost and DSProxyPort, turned off my firewall and antivirus software, checked allows traffic to the proxy ip + port, but the problem has not disappeared.
After few days searches, without results, i decided listening requests from client application and response of my DataSnap Server application in HTTPTrace procedure of DSHTTPService1 component, also with software HTTPDebugerPro, and i noticed interesting thing:
when client app connecting to ds server app without proxy server, in request ds server app receive URI with this text "/datasnap/tunnel" and all works fine ds server response "200, OK".
when client app connecting to ds server app with proxy, in request ds server app receive URI with text "http://[YourServerIP]:[YourPort]/datasnap/tunnel" and raised exception with response error "404, Expected datasnap context in request http://YourServerIP:YourPort/datasnap/tunnel".
Has anyone knows solution about this problem? How to connect DataSnap client to DataSnap server via proxy server? I searched solution for this problem several days, I shoveled the Internet but have not yet found a solution.
I know that with HTTP/1.1 proxies, it's possible to use Keep-Alive to keep a persistent connection with the proxy and from the proxy to the remote server, but I'm curious if/how that would work with an HTTPS connection. I know that to do this, the browser sends a CONNECT request to the proxy to establish a connection then begins communicating using HTTPS. I'm curious if it's possible to use Keep-Alive with HTTPS through an http proxy.
Simply put, CONNECT is always keep-alive.
In HTTP, “persistent connection” means a connection that persists after one request-response pair. But CONNECT establishes a tunnel through the proxy. The proxy cannot even see the requests and responses that are sent over this tunnel (because they are encrypted). So there is no way for this tunnel to not be persistent.
Of course, if the server (the target of CONNECT) decides to close the connection, then the tunnel is destroyed, too. So the server must support persistent connections (just as with a regular, non-TLS proxy).
I am trying to write Connect calls via a NTLM authenticating proxy server. I open a socket to the proxy server and send it a “CONNECT x.x.x.49:80 HTTP/1.1\r\n\r\n”. I expect this to fail as it is an authenticating proxy server but it fails and also closes my connection to the proxy server. I am using Wireshark to check packet values. I can see “Proxy-Connection: close\r\n”. If I do a GET it does not close the connection.
My question is if it is correct for a failed Connect call to close my socket connection?
I'm not 100% clear about your question - I would not expect the first CONNECT to fail with an NTLM proxy server, as it should have sent a Proxy-Authenticate: NTLM header back.
In any case, proxy server has the full right to close the client-side connection in a case of failure, so the answer to your question is "yes". It is odd that it does not do the same for GET, however proxies are more limited with what they can do as a response to CONNECT, and this one may decide that it can't support HTTPS for your request.