1

I often find myself debugging websites or analyzing what goes on under the hood. Fiddler has served me incredibly well for this, and often times I have it running.

I just noticed a very strange issue in which when I access a particular site while Fiddler is running, I get served with a 429 response. If I toggle it to not capture traffic, the site works just fine. The moment I turn it back on, 429 again. I have tried crafting the request myself to see if I can reproduce a 200, but to no avail.

I'm very intrigued by this, because it would seem like the site is detecting that Fiddler is running, but I can't quite wrap my head around it. I suppose that sites could be doing checks using JS and maybe WebSocket workers to detect this stuff, but how does the initial request immediately fail with a 429 just by having Fiddler intercept traffic?

EDIT: Reading https://stackoverflow.com/a/62194160/3511297 suggests that the TLS handshake certificate provided by Fiddler might be the key here.

EDIT #2: Reading up on it, it seems like Fiddler is unable to generate TLS 1.3 certificates, so that might be something, however according to ssllabs.com/ssltest , the site supports TLS 1.0, TLS 1.1, and TLS 1.3

Zuiq Pazu
  • 285
  • 1
  • 4
  • 12

1 Answers1

0

There are no TLS 1.3 certificates. Certificates in SSL/TLS are independent of the used TLS version. Only the used key-pair algorithm (e.g. RSA, ECC, ) can limit the TLS ciphers that can be used. But that only affects the connection between client and Fiddler not the connection to the server (which denies access).

Regarding the supported TLS versions Fiddler is a Windows/.Net application, therefore it inherits the TLS capability of Windows. According to some posts here of SO you may have to manually enable TLS 1.3. Also don't forget to enable tls1.3 in Fiddler HTTPS options.

But if there is really SSL/TLS fingerprinting used on server side I doubt that this is enough to change the fingerprint to something accepted. Usually the complete list of cipher suites as well as optional extensions like Application-Layer Protocol Negotiation (ALPN) also go into the fingerprint and I don't think you can enable such extensions in Fiddler without changes to Fiddler's code.

If you want to check the TLS fingerprint of Fiddler and your web browser(s) you can use Wireshark. Capture the TLS handshake traffic and then apply the run-time filter ssl.handshake.type == 1 (show only CLIENT_HELLO). Expand the entry Transport Layer Security -> TLSv1? Record Layer... -> Handshake Protocol: Client Hello and scroll down.

You will find two lines starting with JA3 (which is the name of a common TLS fingerprinting algorithm) like these:

[JA3 Fullstring: 771,4865-4867-4866-49195-49199-52393-52392-49196-49200-49162-49161-49171-49172-156-157-47-53,0-23-65281-10-11-16-5-34-51-43-13-45-28-41,29-23-24-25-256-257,0]
[JA3: c279b0189edb9269da7bc43dea5e0c36]

using the Fullstring you can compare CLIENT_HELLO messages of different clients.

Robert
  • 39,162
  • 17
  • 99
  • 152