Fiddler is a program for intercepting HTTP/HTTPS traffic. It’s similar to Wireshark widely used on universities when learning networking and TCP/IP protocol stack. The advantage is, it is more focused on application layer of TCP/IP stack which is main concern when debugging Android apps. Because of that, it provides better overview of network traffic from the application perspective and provides features like replying captured requests one again for backend testing.
After you download the program for your platform (https://www.telerik.com/fiddler) you need to follow steps bellow to be able to intercept all traffic (including HTTPS traffic) on your Android device. In shortcut, you mainly just need to:
This is manual for MacOS operating system and Android devices, but can be applied to any other OS as well as any other mobile platform like iOS with slight modification.
Fiddle Everywhere > Preferences
and make sure Capture HTTPS traffic option has been enabled.We really don't need to trust that root certificate (set by default). But that button actually generates public-private key pair and corresponding root certificate that must be installed on the mobile device (as described in bulletpoint 5) and without that you cannot set Capture HTTPS traffic option. However, trusting of that certificate will really be used just for intercepting traffic made on Web browser on your computer.
Fiddle Everywhere > Preferences > Connections
ipv4.fiddler:<Fiddler listening port>
on your mobile device and download self-signed/root certificate of CA (certification authority). If you are not able to access that page, it means you haven’t setup proxy properly or your IP address, proxy port doesn’t correspond to it. It can also mean that your computer and mobile device are using different local network (you are connected to different wireless networks with different SSIDs, or you have setup VPN connection on your mobile device). When you need to use different network location during debugging/network traffic interception, you need to setup VPN network just on side of computer, for the communication with mobile device the original local network is being used, so interception would work. Also since computer is connected to the Interned via VPN tunnel device is using this differently-located Internet connection as well. Self-signed or root certificates cannot be verified by another CA (they are actually verified by itself because they are signed by private key that pairs to provided public key in that certificate, rather then private key that pairs to public key of different CA certificate), but rather must be directly installed/stored in the trusted root certificates (TRC) list on the device and always be trusted when they are found in the TRC list (verification is done just by simple comparison of hashes).OPTIONAL Install self-signed/root CA certificate
Install & run application you want to debug. Be aware, Android apps from some Android API version don’t use those user-added CA certificates by default for security reasons. You need to declare that specifically (for security reasons, it is better to declare just for debug builds) in network_security_config.xml
configuration file like follows. You can also add the certificate directly as Android raw resource, in which case you don’t need to install that (this is reason while bulletpoint 6 is optional). This is also more secure option - even the proper applications are definitely not supposed to use user-added certificates, and Fiddler generates unique root certificates per user per machine, still unwanted HTTPS communication can be observed because regular computer is not intended to work like certification authority. The private key could be stolen when computer is insufficiently secured and attacker could then intercept basically every HTTPS traffic as a man-in-the-middle.
If the application was already installed and running, even with enabled user certificates / added Fiddler root certificate and you reset that certificate you firstly need to add new certificate, optionally create new APK (in case you are using raw resource) and force quite and restart the app to make it work.
When you set the proxy, all network requests made by your application are going through Fiddler. When using HTTPS traffic, it sends you fake HTTPS End-entity certificate which is signed using Fiddler’s once generated self-signed/root CA certificate private key, so it is being verified using that CA certificate public key on the mobile device, CA certificate is self-signed, so it is verified by finding its hash in the TRC list. It is successfully verified because it is found in the user-added TRC list because you already installed that on your device before and which is used for search because you allowed that in the network_security_config.xml
file. Then fake HTTPS connection has been established with Fiddler. Fiddler forwards all the requests to real HTTPS server, that sends real HTTPS certificate signed by real third-party CA, but since HTTPS session has been initialised between Fiddler and HTTPS server, Fiddler is now able to intercept all the communication.
What is really important for security, it’s impossible for the attacker to get (usually publicly available root CA certificate) and generate his own public-key pair and own root CA certificate, that would lead to the same hash. Since verification of root certificates is performed using hash comparison this would be big security issue. This is ensured by property of good hash function. It is irreversible when compared to asymmetric ciphering (where it is possible using private key, while it is impossible to find private key from public key) and you cannot find two different messages based on known hashed message.
CA certificate - when already verified, certificate is used for verification of integrity of another CA certificate or End-entity certificate (nobody but CA that owns this certificate could have been the originator of another CA or End-entity certificate, and nobody can change the it; note: it must owns it, meaning have its private key, not just issues it and signs it)
End-entity certificate - when already verified, certificate is used for verification of confidentiality of message for the side which owns that certificate (HTTPS server), and for verification of integrity of message (nobody but certificate owner could have been the originator of message and nobody can change the message)
Root/self-signed CA certificate - CA certificate that can be verified by itself, in other words - he is his own issuer, so interposed public key can be used for signature verification. It is at the end of the so-called chain of trust.
CA - certification authority
TRC - trusted root certificate
other abbreviations are commonly known abbreviations