I'm using fiddler to decrypt https traffic from a mobile app which was working fine till someone said it wouldn't work for him, after isolating the user and testing different accounts (app requires authentication), I realized his specific account behavior connection was different and it fails every time the app wants to stablish the secure channel with the server. After capturing a few good/bad sessions and comparing I noticed that although the same TLS 1.2 protocol is being used by both of them, every time the client declared is was capable of managing newest TLS 1.3 and reserved ciphers are used fiddler seems not to be able to stablish the connection.. I understand TLS 1.3 hand-shake is different and improved over TLS 1.2 but as I said both seem to use TLS 1.2 (I also notices the user agent declaration is different but don't think it's relevant). I'm of course not security expert and certificates and protocols are not my best strength so I'm looking for some guidance here on how to debug further to address my issue. I tried adding TLS 1.3 to the supported protocols but of course it didn't work (it would not even save the modified string) and then learned fiddler has dependency on .net support also. I'm running fiddler in a Windows 2019 server and as so far I could find it's not possible yet to configure the server to accept TLS 1.3 (as server, client is different), but I'm not even sure if I'm looking this on the right path.
Here is a good connection:
CONNECT xxxxx.yyyyy.com:443 HTTP/1.1
Host: xxxxx.yyyyy.com
User-Agent: /iphone/4.241.10001
Connection: keep-alive
Connection: keep-alive
A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.
Version: 3.3 (TLS/1.2)
Random: AF 05 C3 7D 33 D7 B8 97 66 0A 1E 36 7F 4E 1C 1B 99 F3 4B EC 4D EF A1 73 FE 07 8A 87 AD 76 E6 4C
"Time": 11/10/2036 7:29:35 AM
SessionID: 35 3B 00 00 94 37 B2 B8 9B 63 8D 94 B4 1D 58 A8 3C D6 8B 2B D0 91 49 A2 86 5C CF 65 93 79 AB AD
Extensions:
renegotiation_info 00
server_name xxxxx.yyyyy.com
extended_master_secret empty
signature_algs ecdsa_secp256r1_sha256, rsa_pss_rsae_sha256, rsa_pkcs1_sha256, ecdsa_secp384r1_sha384, rsa_pss_rsae_sha384, rsa_pkcs1_sha384, rsa_pss_rsae_sha512, rsa_pkcs1_sha512, rsa_pkcs1_sha1
status_request OCSP - Implicit Responder
SignedCertTimestamp (RFC6962) empty
ec_point_formats uncompressed [0x0]
supported_groups x25519 [0x1d], secp256r1 [0x17], secp384r1 [0x18], secp521r1 [0x19]
Ciphers:
[C02C] TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
[C02B] TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
[C024] TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
[C023] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
[C00A] TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
[C009] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
[CCA9] TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
[C030] TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
[C02F] TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
[C028] TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
[C027] TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
[C014] TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
[C013] TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
[CCA8] TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
Compression:
[00] NO_COMPRESSION
And here is the bad (unsuccessful) one:
CONNECT xxxxx.yyyyy.com:443 HTTP/1.1
Host: xxxxx.yyyyy.com:443
Connection: keep-alive
User-Agent: Cronet/78.0.3904.84
A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.
Version: 3.3 (TLS/1.2)
Random: 24 CC E5 01 0A 78 1E 18 F9 73 7F 75 FB DF 67 E1 FA A7 FF D8 64 8E E6 9D E4 C9 05 77 88 B7 25 D0
"Time": 1/4/1971 6:40:20 AM
SessionID: 7D BB 95 E2 C8 0F 37 12 FF 2D EC 20 80 24 5D 3B 10 34 7C D8 4D 54 DF 1C 82 16 7D 30 2B EA 64 AD
Extensions:
grease (0x6a6a) empty
server_name xxxxx.yyyyy.com
extended_master_secret empty
renegotiation_info 00
supported_groups grease [0x2a2a], x25519 [0x1d], secp256r1 [0x17], secp384r1 [0x18]
ec_point_formats uncompressed [0x0]
SessionTicket empty
ALPN h2, http/1.1
status_request OCSP - Implicit Responder
signature_algs ecdsa_secp256r1_sha256, rsa_pss_rsae_sha256, rsa_pkcs1_sha256, ecdsa_secp384r1_sha384, rsa_pss_rsae_sha384, rsa_pkcs1_sha384, rsa_pss_rsae_sha512, rsa_pkcs1_sha512, rsa_pkcs1_sha1
SignedCertTimestamp (RFC6962) empty
key_share 00 29 2A 2A 00 01 00 00 1D 00 20 0B 2A 17 56 D8 37 26 5C 47 91 C9 EC DB 0F 89 D4 CD 86 16 38 74 8C 9D 68 CD 82 B2 3F CE D5 48 37
psk_key_exchange_modes 01 01
supported_versions grease [0xeaea], Tls1.3, Tls1.2, Tls1.1
0x001b 02 00 02
grease (0x5a5a) 00
padding 200 null bytes
Ciphers:
[0A0A] Unrecognized cipher - See https://www.iana.org/assignments/tls-parameters/
[1301] TLS_AES_128_GCM_SHA256
[1302] TLS_AES_256_GCM_SHA384
[1303] TLS_CHACHA20_POLY1305_SHA256
[C02B] TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
[C02F] TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
[C02C] TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
[C030] TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
[CCA9] TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
[CCA8] TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
[C013] TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
[C014] TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
[009C] TLS_RSA_WITH_AES_128_GCM_SHA256
[009D] TLS_RSA_WITH_AES_256_GCM_SHA384
[002F] TLS_RSA_WITH_AES_128_CBC_SHA
[0035] TLS_RSA_WITH_AES_256_CBC_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
Compression:
[00] NO_COMPRESSION
Hope someone can help :-)
8 Answers, 1 is accepted
Rank 2
Iron
Hi Carlos,
We have enterprise support for Fiddler which can be purchased from the Fiddler Product site. Let me know if once this is completed and I can convert this to a support ticket. This way we can review details in a secure manner.
As for the issue, I am not entirely certain but it appears that this is working on an iPhone and not on an Android phone? The Cronet User-Agent header appears to be related to the Android Network stack. Can confirm this is the case?
In the meantime, please let me know if you need any additional information. Thank you and I look forward to your reply.
Regards,
Eric R | Senior Technical Support Engineer
Progress Telerik
Rank 2
Iron
Hi Eric,
Thank you for taking the time to read my question. Both captures are actually from the same device and app which is why I thought it was a very odd issue .. not sure why the same app from on the same device will use a different User-Agent based on the user account .. I guess it is worth mentioning this is no my app nor I have any access to the developer to ask that question but I was surprised too when I saw the difference in the User-Agent. I'll check into the premium support option, I thought it's only available for other "paid" products, wasn't sure about Fiddler since I couldn't find anything specific. Perhaps you could send a direct link to the email in my profile?
Cheers,
Carlos.
Rank 2
Iron
Hi Carlos,
I am not certain on the monthly option. I would have to reach out to sales with your information. Let me know if you would prefer that I do that.
As for the application, there could be other mechanisms in-place that cause the TLS upgrade for that specific account. However, since these are platform specific Fiddler won't be able to do anything that alters this behavior. Generally, the purpose of Fiddler is to debug web and mobile applications that a developer owns.
I hope this helps. Please let me know if you need any additional information regarding Fiddler. Thank you for using the forums.
Regards,
Eric R | Senior Technical Support Engineer
Progress Telerik
Rank 2
Iron
Hi Eric,
I found this in regards to Cronet:
"Cronet is the networking stack of Chromium put into a library for use on mobile. This is the same networking stack that is used in the Chrome browser by over a billion people. It offers an easy-to-use, high performance, standards-compliant, and secure way to perform HTTP requests. Cronet has support for both Android and iOS."
From this page https://medium.com/the-react-native-log/using-cronet-in-your-mobile-app-7dda3a89c132
So it seems to me the provider of the app is starting to roll out changes using this new protocol (HTTP3= HTTP2 over QUIC) .. I guess it's time to do some more profound reading and figure out some test cases .. maybe you can comment on how/if this would be something the Fiddler currently support or if it'd need to be implemented?
Rank 2
Iron
Hi Carlos,
That sounds good I will forward your information on to the sales team. For HTTP3, at this time, it is still in draft status and would need to be implemented once it becomes standard.
Although, we appreciate your feedback and as a token of gratitude, I have created a Feature Request for HTTP3 Support. Additionally, I cast a vote on your behalf. I encourage following the item to receive future updates.
In the meantime, please let me know if you need any additional information. Thank you.
Regards,
Eric R | Senior Technical Support Engineer
Progress Telerik