2

I'm using Boost:Asio to perform HTTP GET (Using the example from http://www.boost.org/doc/libs/1_50_0/doc/html/boost_asio/example/http/client/async_client.cpp)

I'm not seeing my requests on fiddler (Only on WireShark) How can i change it?

Sam Miller
  • 23,808
  • 4
  • 67
  • 87
koby meir
  • 437
  • 7
  • 16

2 Answers2

0

Asio works at the socket level and is not using wininet - so fiddler is not able to catch its traffic.

I have been looking for a solution to this, and to make fiddler work with asio you need to use it as a proxy. To enable proxy in fiddler you use Tools -> Telerik Fiddler Options -> Connections.

To use proxy server with asio, you need to use its IP address + port instead of the destination one. Then in GET you need to provide full destination uri - no only the path. For better explanation see here: how to add proxy support to boost::asio?

Community
  • 1
  • 1
marcinj
  • 48,511
  • 9
  • 79
  • 100
0

I have a similar problem about how to solve it, so I just share my experience. So far as I know, Asio works at the socket level and is not using wininet as @marcinj have pointed out and Fiddler works on wininet, but we are still able to do it by using Fiddler as a proxy.

First, explain why it doesn't work on Boost:Asio like interprecting traffics on IE?

See also how to catch the socket programming's send and receive request in fiddler

Fiddler inserts itself into the stack as an HTTP proxy server. It relies on the web browsers to recognize that there is a proxy configured on the PC and to send through that. Your code does not detect for a proxy to send through - so Fiddler won't be able to monitor your traffic.

You have several options.

  1. Since you are own Windows, just switch from using direct sockets to using the WinInet HTTP API. It will do automatic proxy detection for you without you having to think about it. It will do the proxy authentication as well if its required.

  2. OR. Use Wireshark or NetMon to analyze your traffic instead of Fiddler.

I'd recommend #1 since that means your code will work in the presence of a real proxy server (commonly found on enterprise networks) and Fiddler will just work with it.

I suppose there is a third option where you auto-detect the browser proxy settings, then create a socket to the proxy, speak the HTTP PROXY protocol, etc... but that's not the best practice.

Second, how to do?

There's a good example about passing a proxy address to create a client based on Boost:asio like Socket(java.net.Proxy) or Configure a PHP/cURL Application to Use Fiddler, or the client application is not writen by yourself, but if you can control/configure your client connection endpoint address and port, we can make Fiddler intercept HTTP(s) traffics by in any way (re-route HTTP requests as HTTPS requests or re-route HTTPS requests as HTTPS requests for a HTTPS server) as a reverse proxy (requires one argument).

By default, Fiddler is listening on 8888. If go to http://localhost:8888/ in a browser, it presents a default page like:

<!doctype html>
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Fiddler Echo Service</title></head><body style="font-family: arial,sans-serif;"><h1>Fiddler Echo Service</h1><br /><pre>GET / HTTP/1.1
Host: localhost:8888
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36
DNT: 1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9
Cookie: _ga=GA9.1.123456789.1234567890

</pre>This page returned a <b>HTTP/200</b> response <br />Originating Process Information: <code>chrome:3628</code><br /><hr /><ul><li>To configure Fiddler as a reverse proxy instead of seeing this page, see <a href='http://fiddler2.com/r/?REVERSEPROXY'>Reverse Proxy Setup</a><li>You can download the <a href="FiddlerRoot.cer">FiddlerRoot certificate</a></ul></body></html>
  1. If the target server is a HTTP server or the target server is a HTTPS server and the client supports for HTTP depending on your configured address, the just add the following code inside OnBeforeRequest (in Rules -> Customize Rules... Ctrl+R, FiddlerScript), see also Modifying a Request or Response.
//MessageBox.Show(oSession.fullUrl);
// string Session.fullUrl: Retrieves the complete URI, including protocol/scheme, in the form http://www.host.com/filepath?query.
//FiddlerObject.log("Session.fullUrl=" + oSession.fullUrl);
// string Session.url: Gets or sets the URL (without protocol) being requested from the server, in the form www.host.com/filepath?query."
//FiddlerObject.log("Session.url=" + oSession.url);
// string Session.PathAndQuery: Returns the path and query part of the URL. (For a CONNECT request, returns the host:port to be connected.)
//FiddlerObject.log("Session.PathAndQuery=" + oSession.PathAndQuery); // e.g. /filepath?query but host:port for a CONNECT request
// string Session.host: Gets/Sets the host to which this request is targeted. MAY include IPv6 literal brackets. MAY include a trailing port#.
// int Session.port: Returns the server port to which this request is targeted.
//FiddlerObject.log("Session.host=" + oSession.host + ", port=" + oSession.port);
// string Session.hostname: DNS Name of the host server (no port) targeted by this request. Will include IPv6-literal brackets for IPv6-literal addresses
//Gets/Sets the hostname to which this request is targeted; does NOT include any port# but will include IPv6-literal brackets for IPv6 literals.
FiddlerObject.log("Session: hostname=" + oSession.hostname +  ", oRequest.pipeClient.LocalPort=" + oSession.oRequest.pipeClient.LocalPort);


//bool Fiddler.Utilities.isLocalhostname(sHostnameWithoutPort))
// Determines if the specified Hostname is a either 'localhost' or an IPv4 or IPv6 loopback literal
// Returns true if True if the sHostname is 127.0.0.1, 'localhost', or ::1. Note that list is not complete.

// Run Fiddler on your machine, and then add this block of code and test it works on the your same machine:
// Use the `curl http://localhost:8888/get`command  or Using a browser, go to http://localhost:8888/get.
if (Utilities.isLocalhostname(oSession.hostname)) {
    // By default, Fiddler is listening on 8888. Inspect what ports are being listened using proexp or netstat
    // :: Lists the listening ports of a process with the specified image name including extension name(case-insensitive), fiddler.exe
    // for /f "skip=1 tokens=2,9 delims=," %a in ('tasklist /fo csv /fi "IMAGENAME eq fiddler.exe" 2^>NUL') do (netstat -ano | findstr "PID LISTENING" | findstr "PID %a")
    //oSession.host = "httpbin.org:443"; // oSession.oRequest.headers.UriScheme = "https";
    oSession.fullUrl = "https://httpbin.org" + oSession.PathAndQuery;
}

You can compare the expected response using the actual url with the above response by the url localhost connecting the Fiddler proxy who forwards the request to the actual url, i.e. httpbin.org.

  1. If the target server is a HTTPS server, but the client doesn't support for HTTP, rhe changes above are not enough.

Using the command curl -v https://localhost:8888/get (or a browser), we found an error

* schannel: sent initial handshake data: sent 182 bytes
* schannel: SSL/TLS connection with localhost port 8888 (step 2/3)
* schannel: failed to receive handshake, need more data

Inspect the traffic in Wireshark, I found Fiddler didn't perform any HTTPS handshake after the client sent the first TLS request (Client Hello).

Fiddler outputs a log:

18:28:44:5960 HTTPSLint> Warning: ClientHello record was 508 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance

To solve it, we need to do in addition to the rule script:

  1. Configure Fiddler as a reverse proxy server, which forwards all request whose destination port equal the second parameter !listen command to the target server. Click Tools > Fiddler Options > Connections. Ensure "Allow remote clients to connect" is checked. It enables fiddler to respond to the SSL/TLS handshake request of HTTPS. This step is a persistent configuration.

  2. Create a new DWORD named ReverseProxyForPort inside HKEY_CURRENT_USER\SOFTWARE\Microsoft\Fiddler2. Set the DWORD to the local port where Fiddler will re-route inbound traffic (usually port 80 for a standard HTTP server).

:: reg query HKEY_CURRENT_USER\SOFTWARE\Microsoft\Fiddler2 /v ReverseProxyForPort
reg add HKEY_CURRENT_USER\SOFTWARE\Microsoft\Fiddler2 /v ReverseProxyForPort /t REG_DWORD /d 58080 /f && REM /f Force overwriting the existing registry entry without prompt to 58080
:: Deletes the registry key
:: REG DELETE HKEY_CURRENT_USER\SOFTWARE\Microsoft\Fiddler2 /v ReverseProxyForPort  /f && REM /f Forces the deletion without prompt.
  1. Restart Fiddler and start a proxy server listening on a specified port by the !listen *PORT [CERTHOSTNAME]* script-command inside Fiddler's QuickExec box at the lower-left corner by typing!listen 443 ServerHostName, where ServerHostName is whatever the server's hostname is; for instance, for https://Fuzzle/ you would use fuzzle for the server name.

It doesn't seem necessary to create a new DWORD named ReverseProxyForPort inside HKEY_CURRENT_USER\SOFTWARE\Microsoft\Fiddler2 in the windows registry (REGEDIT.exe).

QuickExec - Default commands

!listen *PORT [CERTHOSTNAME]*

Set up an additional listener on another port, optionally secured by a HTTPS certificate

!listen 8889
!listen 4443 localhost
!listen 444 secure.example.com

See also

samm
  • 620
  • 10
  • 22