What's the best way to check if a proxy workable in Qt? - c++

I'm sending HTTP requests with QNetworkAccessManager example.
QNetworkProxy proxy;
proxy.setType(QNetworkProxy::HttpProxy);
proxy.setHostName("some proxy IP");
proxy.setPort(5555);
network_manager.setProxy(proxy);
I want to check if a proxy can work before using it. I know I can just send a HTTP request to google with this proxy. But it will receive more than 1K data. It's relatively large since I would test many proxies. I don't think that's a good way. And I wanted to send ping via the proxy server. Seems no good way to send ping with Qt. If I use the WinAPI IcmpSendEcho to send ping, there's no way to assign a proxy.

Since you want to use the proxy using HTTP you could try and connect to the proxy using a QTcpSocket and see if the connection is actually established. If so you can proceed using the proxy address and port for further connections.

Related

SSL tunnel with Boost::Beast

I want to connect to a proxy server that only allows HTTP connections, to speak with the target server by HTTPS.
The proxy server documentation states that the only way to do that is by means of the HTTP Connect verb (they are planning to add direct HTTPS connections to the proxy server itself, but for the moment only HTTP connections are allowed).
In my C++ program, I successfully connected and worked with the target server using ssl_stream's during a couple of months, using boost::asio without boost::beast, but I want now to use a proxy using boost::beast to make things easier; so, I now how to work with boost::asio but I'm a boost::beast newbie (and I don't fully understand how SSL works either).
The think is that, in my understanding, when you use a ssl_stream, you encript the whole communication, however, what I need now is to insert the encrypted message within the CONNECT HTTP body, and I don't know how to do that.
I've readed that this has something to do with the lowest_layer/next_layer thing but I'm not sure.
Could anybody provide an example of a full read/write connection with a proxy-server? or at least further clarifications?
Declare a variable for the connection (ioc is the io_context)
boost::asio::ssl::stream<boost::asio::ip::tcp::socket> stream{ioc};
Build a CONNECT HTTP request message (req) using Beast
Send the request to the proxy in plain-text (note next_layer())
boost::beast::http::write(stream.next_layer(), req);
Read the HTTP response from the proxy
If the response has OK status, the tunnel is established
Now perform the SSL handshake:
stream.handshake(boost::asio::ssl::stream_base::client);
At this point you can write HTTP requests to stream and read HTTP responses from stream using Beast as normal (do not use next_layer() again).

how is the http CONNECT request behaviour?

Recently i started to write a proxy(web debugging) software.
and handled the GET request well.
sometimes i get CONNECT messages from the client, so i connect to the target server and reply the client by "200 Connection Established".
is that it all??
because after it i don't get any messages
from the server or the client.
so i got confused.
I want to know all the steps of https CONNECT message request and responses until an https site(like https://google.com) gets loaded.
Thank you.
The CONNECT request is used to set up a connection tunnel. This is used mainly to allow access to https sites through an http proxy.
The web proxy is expected to set up a proxy connection to the indicated host, and then proxy the traffic between the two connections, until one or the other terminates.
After establishing the connection, you expect to see either the client or the server start sending something to the other. Your proxy code should be prepared, at any time, to receive more data from either the client or the server, to be forwarded to the other party. If not, your proxy is not doing something correctly. It is not your proxy's job to handle https negotiation. Once the connection is established, your proxy must transparently proxy all the data, and it is the client's and the server's task to talk https with each other.

How to make Qt Websocket and QNetworkRequest (HTTP) to use the same connection?

Is it possible with Qt to upgrade a HTTP connection that handles the normal HTTP requests to a Websocket with the same connection?
I'm thinking about something like this with Poco libraries, but all done in Qt similar to QtWebApp.
The simple answer is no and that is mostly because of specifics of the server side. And Qt just follows the protocol available and exposed by the server (HTTP/WebSocket) as mostly the client-side development framework and AFAIK won't be able to do the kind of transformation you want of going from HTTP to Websocket that are two different protocols. But of course, theoretically that can be done as long as both protocols able to use IP port 80. But that implies new unique sever and new unique client implementations.
We use both WebSocket and REST in our app. And WebSocket is for triggering the client by the server to do something. Client gets the "poke" from the server and starts normal JSON HTTP-based exchange with the server.
Somewhat relative link: https://softwareengineering.stackexchange.com/questions/276253/mixing-rest-and-websocket-in-the-same-api

boost asio client authentication

I have a client server based c++ application which communicates over network (with boost asio) and I am planning to distribute this client application to my customers. My problem is I don't know how to prevent connection request from other applications, that is how can I make sure that only my client application is able to connect to my server. I think there is no way to do this without making the connection, than what is the best way to verify that request is coming from my client?
You can use asio's builtin SSL ability. So, you generating sertificates for each server, and client sertificates. So you can check client sertificate on server at the moment of SSL handshake. As a bonus, your traffic will be encrypted and SSL-secure. Clients can check server is not a fake; server can check clients are authorized.
Yes you have to accept the connection in order to know if it's from your application or not.
You can use a three-way handshake at the connection step:
Client connects to the server The server is sending an specific
value (integer, strings or whatever) to the new client.
The client handles this value, compute a new one with it and sends
the new value to the server.
The server checks if the returned value is correct or not.
The client will have the same compute method as the server. The others applications will not be able to use your service if they returned a bad value.

How are passwords sent for websocket's authentication in CF10?

On the doc Specifying WebSocket authentication details, it did not mention how are passwords being sent from client's authenticate() JS func to server's onWSAuthenticate. Are they being sent through a secure channel? or in plain text?
Side question: what tool / browser / browser's plugin can one use to sniff through websocket's traffic?
Thank you.
username/password sent through authenticate() function is in clear-text. You can actually see that in cfwebsocket.js (its minified so search for authenticate). On server if the call is for authentication, it would invoke onWSAuthenticate() in application.cfc passing whatever username or password given to the function. So the logic of encryption/decryption/validation lies with the developer.
Any TCP monitor can be used for sniffing websocket's traffic like wireshark , TCPMon etc
Mostly just answering to further my own understanding of how this works. From the websocket.org site:
The tunnel is established by issuing an HTTP CONNECT statement to the proxy server, which requests for the proxy server to open a TCP/IP connection to a specific host and port. Once the tunnel is set up, communication can flow unimpeded through the proxy. Since HTTP/S works in a similar fashion, secure WebSockets over SSL can leverage the same HTTP CONNECT technique.
So, if this is what you're asking, it appears that just like with http/https, it's up to the developer to implement SSL encryption, which makes sense.
Sagar Ganatra also has a blog entry on the basics of Websocket Authentication with CF.