Completed
Last Updated: 02 Feb 2022 14:45 by Oleg
This is a feature that's present in both the Firefox and Chrome dev tools, and it's incredibly useful. Fiddler is already great, and that would make it so much better :-)
Completed
Last Updated: 18 Jan 2022 08:43 by ADMIN
This seems to happen a non-trivial number of times, and it causes clients and scenarios to fail in surprising ways.
Completed
Last Updated: 18 Jan 2022 07:10 by ADMIN

When HTTPS decryption is enabled in Fiddler, Fiddler parses the ClientHello and ServerHello HTTPS messages to determine the supported ciphers and other information, including TLS Extensions.

Unfortunately, Fiddler's HTTPSMessages parsers have a bug whereby if the extensions are larger than the available data on the stream/pipe, reading of the extensions is skipped and misleading text suggesting that no extensions were sent is shown in the Inspectors. For instance, the current version of Chrome Canary sends ~1308 bytes of TLS extensions in the ClientHello, but only 908 bytes are available at the time that the message is read. Fiddler claims that the ClientHello contained no extensions. 

Instead of performing a single .Read() call and ignoring the result if the size is less than expected, Fiddler should continue to read the stream until the promised number of bytes have been read.

 

[This issue is similar to https://crbug.com/1028602#c2, although the implementation is obviously unrelated).

Completed
Last Updated: 22 Dec 2021 06:37 by ADMIN

The GetSupportedVersions function inside HTTPSUtilities has an off-by-one error in the parser that results in omitting the final value in the list.

Instead of code like this:

    for (int index = 1; index < arrSupported.Length - 2; index += 2)

 

the code should instead be:

 

    for (int index = 1; index <= arrSupported.Length - 2; index += 2)

Completed
Last Updated: 07 Dec 2021 11:03 by ADMIN

Precondition:

  • Have a list of several AutoResponder rules.

Steps to reproduce:

  • Select a rule in the list.
  • Press the M hotkey to set a comment for the rule.
  • Edit the comment.
  • Save the comment by confirming with OK.

Expected result:

  • The comment edit dialogue displays the current comment of the rule selected in the list.
  • Confirming the dialogue updates the comment of the rule selected in the list with the text box content.
  • The list selection does not change.

Actual result:

  • The comment edit dialogue displays the current comment of the rule selected in the list (expected).
  • As the edit dialogue opens, the selection in the AutoResponder list changes and a different rule is highlighted.
  • Confirming the dialogue updates the comment of the newly selected rule, not the one the user manually selected and whose initial comment was shown in the edit dialogue.

Version: 5.0.20192.25091 (2019-06-04)
Platform: Windows 10 build 17134, .NET 4.7.1

Completed
Last Updated: 07 Dec 2021 11:01 by ADMIN

Inside the Header inspector, you can add a header to a breakpointed response. The header editor offers templates. The "Set-Cookie" template for persistent cookies has an expiration date that seemed impossibly far in the future: June 2021.

 

Well, I may not have a flying car, but we're now living in a future beyond that imagined by the header inspector. We need to update to a later expiration date.

Completed
Last Updated: 07 Dec 2021 10:59 by ADMIN

The bug I'm reporting is sometimes the Session.HostnameIs() will return true even if the supplied hostname does not match Session.hostname and a port was passed by the client in the Host header.

HostnameIs function is documented as "This method compares the supplied hostname to the hostname of the request, returning true if a case-insensitive match is found."

What I think is happening is that rather than use Session.hostname for comparison Fiddler instead uses the Session.host (ie what was passed by the client in the Host header) and if a port is present maybe it incorrectly extracts out the hostname. Here is an example that shows the bug and why I think that.

In OnBeforeRequest add this code, which should only show an alert box if the hostname is test:

		if(oSession.HostnameIs("test")) {
			FiddlerObject.alert(oSession.hostname);
		}

Now in a browser try going to http://t:81/ and you will see it shows the alert box, in other words a match. Why? Well, I will guess based on my testing that your code in HostnameIs gets the index of the colon in the host t:81, which is 1, and then compares only that number of characters. So it's doing whatever is the javascript equivalent of !strnicmp("t", "test", 1).

This manifests itself through CONNECT as well, and probably more likely, since the standard ports are used in the Host header (IE might be an exception to this). For example, let's say you go to https://t/ in Firefox or Chrome and HTTPS decrypt is enabled. The Host passed by the client for the CONNECT is t:443 and so it's the same problem, !strnicmp("t", "test", 1).

This is not a theoretical issue for me, I was testing something earlier today where I had to treat a hostname that ended in .co different from the same hostname that ended in .com and it turned out the test I was doing applied to both of them because of this bug.

There may be very good reason to not use Session.hostname for the comparison, I don't know, but the likely extraction from Session.host is not done properly.
Completed
Last Updated: 07 Dec 2021 10:57 by ADMIN

https://twitter.com/ozziepeeps/status/1349126308454830082

 

Basically, the problem here is that if we're AutoAuthenticating when reissuing a request, we try to strip any default Auth header.

 

There's code that looks like

 

   if (theFlags.ContainsKey("x-AutoAuth") && newSession.requestHeaders["Authorization"].OICContains("NTLM") 

//... strip the header

The problem is that we should only be looking at the very first token of the Authorization header (e.g. before the first space). We should not search the whole header, because if the header is

 

    Authorization: Bearer BlahblahblahNtLMblahblah

 

we think it's an NTLM header and strip it. 

 

Completed
Last Updated: 07 Dec 2021 10:54 by ADMIN

Response headers named


  Cross-Origin-Embedder-Policy
  Cross-Origin-Resource-Policy
  Cross-Origin-Opener-Policy

 

Should be added to the "Security" section of the Response Headers inspector. These are important security headers added to the web platform, and looking for them will become increasingly common and important.

Completed
Last Updated: 07 Dec 2021 10:52 by ADMIN
Created by: Tony
Comments: 2
Type: Bug Report
0

Hi,

When i started latest version of Fiddler, i started to get an error window at launch saying "Failed to register Fiddler as the system proxy"

But as usual, i have plenty opened windows at the same time.

While i'm doing a search for a solution, Fiddler and the error window goes to background.

But when i come back to Fiddler, i'm unable to exit the application.

The error windows is not referenced in the taskbar and it's a pain to find it.

The best solution is to go to desktop "Win+D" and focus on Fiddler to get the splash screen and the error window visible again.

Once the error window closed, i can close Fiddler.

The issue is the error window staying on background and not having an entry in taskbar.

Completed
Last Updated: 07 Dec 2021 10:51 by ADMIN

Fiddler’s “Auth” Inspector uses Encoding.Default() for decoding base64-encoded BASIC auth credentials. This was common practice at the time this was first written but is now obsolete. https://tools.ietf.org/html/rfc7617, written much later, demands UTF-8.

Chromium and Firefox encodes credentials using UTF-8.

https://source.chromium.org/chromium/chromium/src/+/master:net/http/http_auth_handler_basic.cc;l=89;bpv=1;bpt=1

Completed
Last Updated: 05 Oct 2020 05:18 by ADMIN
Created by: Kostas
Comments: 26
Type: Feature Request
64
I find myself applying the same filters again and again on each launch of Fiddler (I mean the filters listed below the list of requests).

I think it would be really great if you could allow the restoration of previously applied filters (e.g. by having a save/load filters option).

Also, allowing to filter out by "Request Method" would be great too.

Congratulations on this tool, by the way.

It is really great. :)
Completed
Last Updated: 29 Apr 2020 13:17 by ADMIN

https://twitter.com/ericlaw/status/1232024946030862336

Today, Fiddler's AutoResponder only automatically replies to a HTTPS CONNECT with a HTTP/200 OK if the capture contains such a response, or if the "Unmatched requests passthrough" box is unchecked. Otherwise, the CONNECT request will pass or fail based on whether the real server is reachable.

This is confusing, and almost never what the user really wants to have happen.

We should add a new checkbox to the AutoResponder titled "Accept all CONNECTs" that when checked, sets a hidden rule equivalent to this rule which can be created manually

    method:CONNECT
    *ReplyWithTunnel

Otherwise, users will be sad when AutoResponder doesn't do what they hope, and they'll wonder why they are getting ERR_TUNNEL_CONNECTION_FAILED error messages in their browser when they have AutoResponder rules for HTTPS requests that they expect to fire.

 

Completed
Last Updated: 28 Apr 2020 13:50 by ADMIN

Date of update appears as 04/21/2019, should be 04/21/2020:

5
0
20202
18177
5.0.20202.18177 [04/21/2019]
features:
 "Accept all CONNECTs" option in AutoResponder
Completed
Last Updated: 20 Nov 2019 11:54 by ADMIN
Created by: Eric
Comments: 0
Type: Feature Request
5
Ensure that traffic from the Brave web browser is properly categorized by the traffic filtering system in the status bar.
Completed
Last Updated: 09 Oct 2019 06:31 by ADMIN
Created by: Eric
Comments: 1
Type: Feature Request
1
Tools > Options > Scripting has a new Language Dropdown.

It should be a DropDownList instead of a dropdown, otherwise, any character the user types causes a popup alert and the user can be left with a garbage value.

Further, there probably shouldn't be an explicit warning that a restart is required, as a great many options on the Options dialog require restart and showing this warning for only one of them may be misleading.
Completed
Last Updated: 07 Oct 2019 10:53 by ADMIN
Created by: Eric
Comments: 6
Type: Bug Report
4

Fiddler's "Web Browsers" filter does not include msedge.exe as a web browser. This is the executable name of the new Chromium-based version of Edge that Microsoft is now working on.

This should be a one-line fix and very much appreciated by the many thousands of Fiddler+Edge users.

Completed
Last Updated: 03 Oct 2019 14:42 by ADMIN
It's huge, doesn't have anything to do with Fiddler besides being a Telerik product, and I have no interest in it after having used previous Telerik toolkits.

People already deal with ads when consuming content.  Don't add them to shit we use when doing work.
Completed
Last Updated: 03 Oct 2019 12:15 by ADMIN
Created by: Eric
Comments: 0
Type: Feature Request
2
https://bugs.chromium.org/p/chromium/issues/detail?id=653691 (https://bugs.chromium.org/p/chromium/issues/detail?id=653691#c5)

Chrome 57 won't accept certificate chains that contain SHA-1 within them, so we need to be sure that Fiddler/FiddlerCore default to SHA-256 everywhere. We also might consider whether we should detect that the user has old Fiddler-generated SHA-1 certificates cached and if so, clean those up and generate a fresh cert using SHA-256.
Completed
Last Updated: 03 Oct 2019 12:13 by ADMIN
Should be "Automatically reload script when changed"

Tools > Fiddler Options > Scripting
1 2