What Is Point of Ssl If Fiddler 2 Can Decrypt All Calls Over Https

What is point of SSL if fiddler 2 can decrypt all calls over HTTPS?

This is covered here: http://www.fiddlerbook.com/fiddler/help/httpsdecryption.asp

Fiddler2 relies on a "man-in-the-middle" approach to HTTPS interception. To your web browser, Fiddler2 claims to be the secure web server, and to the web server, Fiddler2 mimics the web browser. In order to pretend to be the web server, Fiddler2 dynamically generates a HTTPS certificate.

Essentially, you manually trust whatever certificate Fiddler provides, the same will be true if you manually accept certificate from random person that does not match domain name.

EDIT:
There are ways to prevent Fiddler/man-in-the-middle attack - i.e. in custom application, using SSL, one can require particular certificates to be used for communication. In case of browsers, they have UI to notify user of certificate mismatch, but eventually allow such communication.

As a publicly available sample for explicit certificates, you can try to use Azure services (i.e. with PowerShell tools for Azure) and sniff traffic with Fiddler. It fails due to explicit cert requirement.

Why make use of HTTPS when Fiddler can decrypt it

Fiddler performs a MITM technique.

To make it work, you need to trust its Certificate:

http://www.fiddler2.com/fiddler/help/httpsdecryption.asp

If you don't, it won't decrypt anything...

how can Fiddler2 debug HTTPS traffic?

A: Fiddler2 relies on a "man-in-the-middle" approach to HTTPS
interception. To your web browser, Fiddler2 claims to be the secure
web server, and to the web server, Fiddler2 mimics the web browser.
In order to pretend to be the web server, Fiddler2 dynamically
generates a HTTPS certificate.

Fiddler's certificate is not trusted by your web browser (since
Fiddler is not a Trusted Root Certification authority), and hence
while Fiddler2 is intercepting your traffic, you'll see a HTTPS error
message in your browser [...]

Can you decrypt incoming SSL traffic?

Fiddler acts as a man-in-the-middle: it sends its own self-generated certificates, with its own private/public key pairs, to the client. Hence, when the client sends the symmetric key to the Fiddler, it does so using the public key that matches the private key that Fiddler itself already has. See What is point of SSL if fiddler 2 can decrypt all calls over HTTPS? to understand how the browser can be configured to allow this.

After Fiddler gets the decrypted traffic, it resends the requests to the server, pretending to the server like it is the client, using the server's public key to encrypt a new symmetric key that is used to talk from Fiddler to the server.

[Client] -FiddlerPublicKey(SymmetricKey1)--> [Fiddler] -ServerPublicKey(SymmetricKey2)--> [Server]

In contrast, Wireshark can decrypt the traffic when you provide it with the server's private key; it can look for the message where the client sends the symmetric key and decrypt it using the (normally secret) private key that the server ordinarily holds.

Why would some HTTPS requests fail to decrypt on Fiddler, while some works ?

There are plenty of tutorials on how you can intercept HTTP(s) traffic from Android using Fiddler.
Try this one: http://docs.telerik.com/fiddler/configure-fiddler/tasks/configureforandroid

However, it will fail when you try to intercept and decrypt Android SSL traffic coming from an application, and not from a browser.

It might be that the application uses a certificate pinning – and you are probably cannot decipher this connection. Lost cause!
But more probably, the reason is a bug in the HttpsUrlConnection pipeline implementation.

To solve the issue, please proceed with the following steps:

  1. In Fiddler click "Rules->Customize Rules";
  2. Find function OnBeforeResponse in the script
  3. Add following code to the function body:

    if (oSession.oRequest["User-Agent"].indexOf("Dalvik") > -1 &&
    oSession.HTTPMethodIs("CONNECT")) {
    oSession.oResponse.headers["Connection"] = "Keep-Alive";
    }
  4. Save the file and restart Fiddler.

HTTPS traffic from SharePoint in Fiddler not available

If Fiddler is seeing the CONNECT tunnels, but no traffic is going over them, and decryption is enabled, then the service is most likely not trusting the Fiddler root certificate.

Use MMC.exe to launch the Certificate Manager for the MACHINE account and import the FiddlerRoot.cer into the Trusted Store for the machine account.

How secure is SSL connection??

You are basically cooperating with fiddler to launch a Man in the Middle attack against yourself. You trust Fiddler's certificate, so Fiddler then acts as a proxy and pretends to be the website you are talking to, from your perspective (which is possible since you have trusted Fiddler as your proxy). From Hotmail's perspective, Fiddler is pretending to be you.

This is only possible because you have trusted Fiddler. Of course, there is the question about rogue Certificate Authorities, but that's a different matter entirely.



Related Topics



Leave a reply



Submit