I am attempting to create a SOCKS 4/5 server, and I would like to use the Indy TIdSocksServer component as the foundation. It seems straight forward enough and simple to use, but I must be missing something.
I dropped a TIdSocksServer onto a new Form and configured the following:
Active: True
AllowSocks4: True
AllowSocks5: True
Bindings: 0.0.0.0:43334
Default Port: 80
Intercept: null
IOHandler: null
I added code to display 'connect' in a TMemo upon connection:
procedure TForm1.IdSocksServer1Connect(AContext: TIdContext);
begin
Memo1.Lines.Add('connect');
end;
I configured ProxyChains on a Linux host:
/etc/proxychains.conf
...
socks5 10.0.0.56 43334
When I execute the App and try to connect using ProxyChains, I get the following error:
kelly#ubuntu:~/home$ proxychains curl www.google.com
ProxyChains-3.1 (http://proxychains.sf.net)
|DNS-request| www.google.com
|S-chain|-<>-10.0.0.56:43334-<><>-4.2.2.2:53-<--timeout
|DNS-response|: www.google.com does not exist
curl: (6) Could not resolve host: www.google.com
I can confirm that the connection is established, because the text 'connect' gets added to the Memo. I also used Wireshark and observed the three-way handshake and teardown between my Ubuntu host and the Windows host.
It seems the issue is that the traffic is reaching the SOCKS server, but not getting forwarded. I acknowledge that this is absolute minimum code, but I am under the impression that the TIdSocksServer component would take care of forwarding the traffic, and I would add in supporting functions such as validating credentials for SOCKS5, etc.
Remy identified the issue with my code. In order to verify that the server was receiving connections I added a procedure which wrote to a TMemo component, which was causing a deadlock. To fix the error all I had to do was remove the procedure which was updating the TMemo component. Works as expected.
Related
I'm getting whois information using this code:
IdWhois1.Host := 'whois.nic.tld';
ServerResultStr := IdWhois1.WhoIs('google.tld');
But I need to query the whois server (port 43) using a SOCKS proxy server.
I'm using Delphi 10.3.3. Is there any way to achieve this by using TIdWhois?
SOCKS is handled in Indy using the TIdSocksInfo component. You can configure it with the proxy details as needed (Host, Port, Version, Authentication, etc).
To make TIdWhois (or any TCP client) connect to its target server through TIdSocksInfo, you need to do the following:
assign a TIdIOHandlerSocket-derived component (TIdIOHandlerStack, or any TIdSSLIOHandlerSocketBase-derived component, like TIdSSLIOHandlerSocketOpenSSL) to the TIdWhois.IOHandler property.
assign the TIdSocksInfo to the IOHandler's TransparentProxy property.
I'm trying to do a POST request through proxy using https.
Code looks like:
FHttp := TIdHttp.Create(nil);
FHttp.ProxyParams.ProxyServer := Host;
FHttp.ProxyParams.ProxyPort := Port;
FHttp.ProxyParams.ProxyUsername := User;
FHttp.ProxyParams.ProxyPassword := Password;
FHandler := TIdSSLIOHandlerSocketOpenSSL.Create(nil);
FHandler.SSLOptions.Method := sslvTLSv1_2;
FHandler.PassThrough := true;
FHttp.IOHandler := FHandler;
FHttp.HandleRedirects := true;
FHttp.Request.ContentType := 'application/x-www-form-urlencoded';
FHttp.Request.Connection := 'keep-alive';
FHttp.Request.ProxyConnection := 'keep-alive';
...
FParams.Add('username=user');
FParams.Add('password=pwd');
FHttp.Post('https://my.service/login', FParams);
Proxy server is Squid.
Code generates error "Socket Error # 10054 Connection reset by peer."
Now, the interesting part comes:
If not using proxy at all (i.e. not setting FHttp.ProxyParams settings) - everything is OK.
If not setting any POST parameters (i.e. empty FParams), but still using proxy - everything is OK.
The most strange one: If I'm debugging the Indy code step by step (TIdCustomHTTP.DoRequest method) - everything is OK with above example (proxy settings + parameters).
POST parameters are not sent properly for some reason?
And why step 3 is happening?
Indy is up to date, just pulled from repository
UPDATE
After intercepting TIdHTTP calls (thanks Remy) there is a little bit more clarity. (failing log, working log).
Short version: when doing debug, Indy does 3 CONNECT + POST + DISCONNECT requests (because there are redirection on the service I believe) and it works.
When running test without debug - CONNECT + DISCONNECT + POST - and it fails obviously (i.e. POST is executed without CONNECT in front).
See attached log files for details.
You have found some logic bugs in TIdHTTP that need to be fixed. I have opened a new ticket for that:
#315: Bugs in TIdHTTP proxy handling
Here is what I see happening in your "failing" scenario:
TIdHTTP connects to the proxy, sends a CONNECT request that successfully connects to my.service.com:443, then sends a POST request (using HTTP 1.0 rather than HTTP 1.1 a).
a) to send a POST request with HTTP 1.1, you have to set the TIdHTTP.ProtocolVersion property to pv1_1, AND enable the hoKeepOrigProtocol flag in the TIdHTTP.HTTPOptions property. Otherwise, TIdHTTP.Post() forces the ProtocolVersion to pv1_0.
The HTTP server replies with a 302 Found response redirecting to a different URL, including a Keep-Alive header indicating the server will close the connection if a new request is not sent in the next 5 seconds.
When TIdHTTP is done processing the POST response, it knows it is going to re-send the same request to a new URL. On the next loop iteration, it sees that the target server is the same, and the proxy is still connected, and so the connection is not closed, and the code that would have sent a new CONNECT request is skipped.
Just before the POST request is sent, the Response.KeepAlive property is checked to know whether or not to close the socket connection anyway. The KeepAlive property getter sees the ProtocolVersion property is pv1_0 and that there is no Proxy-Connection: keep-alive header present in the response (even though there is a Connection: keep-alive header), so it returns False, and then the socket connection is closed.
TIdHTTP then re-connects to the proxy again, but does not send a new CONNECT request before sending the POST request. The proxy does not know what to do with the POST, so it fails the request with a 400 Bad Request response.
Here is what I see happening in your "working" scenario:
Everything is the same as above, up to the point where the 1st POST request is processed. Then there is a delay of roughly 16 seconds (likely since you are stepping through code) - more than the 5-second Keep-Alive delay allows - so the HTTP server closes its connection with the proxy, which then closes its connection to TIdHTTP.
By the time TIdHTTP is ready to send the 2nd POST request, it knows it has been disconnected from the proxy, so it re-connects to the proxy, sends a new CONNECT request, and then sends the POST request.
Until I can fix the bugs properly, try the following:
enable the hoKeepOrigProtocol flag in the TIdHTTP.HTTPOptions property to allow TIdHTTP.Post() to use HTTP 1.1. That in itself may fix the issue with the connection being closed unnecessarily before sending the 2nd POST request to the redirected URL.
if that doesn't solve the issue, try editing IdHTTP.pas yourself and recompile Indy, to update the TIdCustomHTTP.ConnectToHost() method to force a Disconnect() if the Response.KeepAlive property is False BEFORE the local LUseConnectVerb variable is set to not Connected in the case where ARequest.UseProxy is ctSSLProxy (and ctProxy, too). That way, the 2nd POST request will disconnect from the proxy and re-connect with a new CONNECT request.
example url:
https://api.binance.com/api/v1/time
Using TIdDNSResolver and cloudflare dns I can get the host IP.
direct request in the form of
https://205.251.219.20/api/v1/time
doesn't work cause as I understand the server expects to see "api.binance.com" in the url. (it doesnt work even in browser)
Using synapce and the following patch to replace request's host with resolved IP I make it working
function THTTPSend.InternalDoConnect(needssl: Boolean): Boolean;
begin
Result := False;
FSock.CloseSocket;
FSock.Bind(FIPInterface, cAnyPort);
if FSock.LastError <> 0 then
Exit;
If ResolvedIP.IsEmpty
then FSock.Connect(FTargetHost, FTargetPort)
else FSock.Connect(ResolvedIP, FTargetPort); // !!
Is there any way to do the same using Indy?
By default, TIdHTTP uses the Host:Port that is specified/inferred by the URL that is being requested. To change that behavior, you would have to alter TIdHTTP's source code, such as in the TIdCustomHTTP.SetHostAndPort() or TIdCustomHTTP.CheckAndConnect() method (which are both not virtual), and then recompile Indy.
Alternatively, you could use TIdHTTP's OnSocketAllocated or On(Before|After)Bind event (which are not promoted to published in TIdHTTP, so you would have to access them manually at runtime) to change the TIdHTTP.IOHandler.Host property to whatever IP address you want to connect to. This will not have any affect on the HTTP headers that TIdHTTP sends, such as Host, which will still be taken from the URL.
Alternatively, if you want all of Indy's Host-to-IP DNS queries to go through Cloudflare, you could derive a custom class from TIdStack (or whatever platform-specific descendant you are interested in, such as TIdStackWindows), override its virtual HostByName() method to perform whatever DNS query you want, and then pass your class type to the SetStackClass() function in the IdStack unit at program startup before any Indy classes are instantiated.
I have succesfully used neo4jphp library with graphenedb with this simple steps as per documentation (considering that graphenedb does not require https)
require('vendor/autoload.php'); // or your custom autoloader
// Connecting to a different port or host
$client = new Everyman\Neo4j\Client(url, port);
// Connecting using HTTP and Basic Auth
$client->getTransport()
->setAuth('username', 'password');
// Test connection to server
print_r($client->getServerInfo());
However, when trying to connect to a graphstory instance (of course they both work fine if I call the rest api from browser, the neo4j console works fine etc.) which requires https as follows
require('vendor/autoload.php'); // or your custom autoloader
// Connecting to a different port or host
$client = new Everyman\Neo4j\Client(url, port);
// Connecting using HTTPS and Basic Auth
$client->getTransport()
->useHttps()
->setAuth('username', 'password');
// Test connection to server
print_r($client->getServerInfo());
I get the following error. They should be identical, I can't get why.
Fatal error: Uncaught exception 'Everyman\Neo4j\Exception' with message 'Can't open connection to https://neo-54f500bf2cc7e-364459c455.do-stories.graphstory.com:7473/db/data/' in /Applications/XAMPP/xamppfiles/htdocs/graphene/vendor/everyman/neo4jphp/lib/Everyman/Neo4j/Transport/Curl.php:91
Stack trace:
#0 /Applications/XAMPP/xamppfiles/htdocs/graphene/vendor/everyman/neo4jphp/lib/Everyman/Neo4j/Transport.php(95): Everyman\Neo4j\Transport\Curl->makeRequest('GET', '/', NULL)
#1 /Applications/XAMPP/xamppfiles/htdocs/graphene/vendor/everyman/neo4jphp/lib/Everyman/Neo4j/Command.php(64): Everyman\Neo4j\Transport->get('/', NULL)
#2 /Applications/XAMPP/xamppfiles/htdocs/graphene/vendor/everyman/neo4jphp/lib/Everyman/Neo4j/Client.php(828): Everyman\Neo4j\Command->execute()
#3 /Applications/XAMPP/xamppfiles/htdocs/graphene/vendor/everyman/neo4jphp/lib/Everyman/Neo4j/Client.php(464): Everyman\Neo4j\Client->runCommand(Object(Everyman\Neo4j\Command\GetServerInfo))
#4 /Applications/XAMPP/xamppfiles/htdocs/graphene/story.php(20): Every in /Applications/XAMPP/xamppfiles/htdocs/graphene/vendor/everyman/neo4jphp/lib/Everyman/Neo4j/Transport/Curl.php on line 91
It seems to me that neo4jphp is not configuring the TLS part in the cURL request.
I fixed it by downloading the certificate bundle from http://curl.haxx.se/docs/caextract.html (ca_bundle.crt) and adding the following line to Everyman\Neo4j\Transport\Curl.php, function makeRequest:
$options[CURLOPT_CAINFO] = "your/path/to/ca-bundle.crt";
I've created an issue on GitHub for this: https://github.com/jadell/neo4jphp/issues/171
I'm the CTO/Lead Dev at Graph Story. Sorry to hear you're having troubles. I've actually just taken a look at your instance and things seem OK from the server side.
Without additional info it's hard to say if there's an issue with your sample connection code. Considering that you've used that same library to connect to GrapheneDB in the past, I think the chances an error in the sample code is low.
Based on the current state of your instance and on the exception thrown by Neo4jPHP, my guess is that port 7473 may be blocked on your network. You can confirm that with local tech support or by switching to a network where you know port 7473 is open and trying to connect again.
i want to check my server connection to know if its available or not to inform the user..
so how to send a pkg or msg to the server (it's not SQL server; it's a server contains some serviecs) ...
thnx in adcvance ..
With all the possibilities for firewalls blocking ICMP packets or specific ports, the only way to guarantee that a service is running is to do something that uses that service.
For instance, if it were a JDBC server, you could execute a non-destructive SQL query, such as select * from sysibm.sysdummy1 for DB2. If it's a HTTP server, you could create a GET packet for index.htm.
If you actually have control over the service, it's a simple matter to create a special sub-service to handle these requests (such as you send through a CHECK packet and get back an OKAY response).
That way, you avoid all the possible firewall issues and the test is a true end-to-end one. PINGs and traceroutes will be able to tell if you can get to the machine (firewalls permitting) but they won't tell you if your service is functioning.
Take this from someone who's had to battle the network gods in a corporate environment where machines are locked up as tight as the proverbial fishes ...
If you can open a port but don't want to use ping (i dont know why but hey) you could use something like this:
import socket
host = ''
port = 55555
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind((host, port))
s.listen(1)
while 1:
try:
clientsock, clientaddr = s.accept()
clientsock.sendall('alive')
clientsock.close()
except:
pass
which is nothing more then a simple python socket server listening on 55555 and returning alive