I wrote a little program for capture https traffic. I want to capture DECODED get and post data using that software.
As you know, the Fiddler application can do that like a charm and now i am looking for a way to do that in my program.
For instance, here's my code:
void FiddlerApplication_AfterSessionComplete(Fiddler.Session oSession)
{
this.Invoke(new MethodInvoker(delegate
{
oSession.bBufferResponse = true;
txtLog.Text += "full-url : \r\n" + oSession.fullUrl.ToString() + "\r\n-----------------------------------------------\r\n";
txtLog.Text += "method : \r\n" + oSession.oRequest.headers.HTTPMethod + "\r\n-----------------------------------------------\r\n";
txtLog.Text += "request headers : \r\n" + oSession.oRequest.headers + "\r\n-----------------------------------------------\r\n";
txtLog.Text += "responce headers : \r\n" + oSession.oResponse.headers + "\r\n-----------------------------------------------\r\n";
txtLog.Text += "get request body as string : \r\n" + oSession.GetRequestBodyAsString() + "\r\n-----------------------------------------------\r\n";
txtLog.Text += "request body bytes : \r\n" + oSession.requestBodyBytes + "\r\n>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>\r\n";
txtLog.SelectionStart = txtLog.Text.Length;
txtLog.ScrollToCaret();
}));
}
and get request body as string
in txtLog
for an https web page is like below :
get request body as string :
A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.
Major Version: 3
Minor Version: 1
Random: 52 02 18 75 64 2D 8D 65 75 B9 C4 1B 58 76 92 3E 6B C5 BF 1D 3B D4 53 5D D2 FA CA D8 BF CE 02 5D
SessionID: empty
Ciphers:
[002F] TLS_RSA_AES_128_SHA
what is this handshake part and how can i decode it?
as you know there are two files (TrustCert.exe & makecert.exe) inside installed fiddler application.
what are these files and can i use them inside my little application for decoding data? how?
thanks in advance
The FiddlerCore class library decrypts HTTPS traffic using a man-in-the-middle approach.
As discussed in the Fiddler book:
The HTTPS protocol sandwiches an encrypted (SSL or TLS) connection between HTTP requests and the underlying TCP/IP network connection upon which those requests are sent. Network intermediaries or observers are thus prevented from viewing or modifying the HTTP traffic thanks to the use of the cryptographic protocols. You might then be surprised to learn that Fiddler can both view and modify HTTPS traffic if configured appropriately. Fiddler achieves this by using a “man-in-the-middle” approach to HTTPS, which means that when talking to the client, it pretends to be the server, and when talking to the server, it pretends to be the client.
The HTTPS protocol is explicitly designed to block this attack by using digital certificates to authenticate the identity of a HTTPS server (and optionally the client). When a client receives a certificate from the server, it validates that the certificate itself is trustworthy by determining whether it is chained to a Root Certification Authority that is trusted by the client or the operating system. Since you are typically running Fiddler on your own computer, you can reconfigure your browser or operating system to trust Fiddler’s root certificate. After you do so, the client application will not complain when it detects that traffic is being protected by Fiddler-generated certificates.
If your goal is to embed this capability into your application, you should simply use FiddlerCore in your application-- that's why it exists!
As to your question about the "handshake"-- the handshake is how the client and the server agree on the parameters for the HTTPS communication (e.g. what cipher and keys to use). You don't "decode" the handshake per-se-- FiddlerCore handles this for you.
You might be getting confused because HTTPS traffic runs inside a HTTP CONNECT
tunnel, and that tunnel is also visible in FiddlerCore. To ensure that your HTTPS Sessions are also captured, be sure to pass the FiddlerCoreStartupFlags.DecryptSSL
flag when calling the Startup
method. Also, be sure that makecert.exe
is in the same folder as your program's executable.
Also, keep in mind that setting the bBufferResponse
property after the Session has already completed processing has no effect; you should remove that.