2

I have and iOS application to test. As per the latest security fix SSL pinning is enabled in the app. But now I am not able to see any traffic related to the application in my proxy tool. But interestingly the app works as normal, just that the traffic is not showing up in the proxy.

I have tried with both Burp and ZAP. The application traffic were visible before SSL pinning was implemented. I can see the traffic of google.com from Safari(to confirm that I have configured the proxy tool's CA properly in the iOS device).

What could be the reason? From my understanding, if SSL pinning is set properly and when the proxy tool is introduced, the app should ideally drop all the communication.

I am confused whether it is not being transmitted via Burp. Or does it simply pass my proxy just like a DNS request(which obviously Burp can't see). Additionally I have read this article. It says for some reason Burp won't show up websocket requests if it uses a non standard port. But this is not my case. We don't have websockets.

Any help is appreciated.

Improve this question
1
  • It's hard to investigate the problem without having access to the code/app. Make sure that the application is using HTTP/1.1 protocol. I've once encountered an app that used gRPC which relies on HTTP/2. Burp couldn't "see" such traffic since Burp does not support HTTP/2. So it might be worth it to investigate it further by analyzing the traffic with Wireshark.
    – HamZa
    Jun 12, 2018 at 9:28

2 Answers 2

Reset to default
2

Aside from automatic passthrough (used for connections where Burp's certs are rejected, check Burp's logs), the other possibility is just that the app is no longer using the system-wide proxy settings at all. This is somewhat unconventional, but happens as a natural consequence of some ways of implementing cert/key pinning (typically it happens when a third-party TLS and/or HTTP library is used). If there's no log entries about passthrough traffic, and disabling passthrough doesn't change anything, then that's what's happening.

You can still intercept the traffic in a number of ways (routing the app's traffic to a transparent proxy via DNS or ARP spoofing, or having the device connect to the WiFi network of a computer that is sharing its connection in "hotspot" mode such that the traffic naturally flows through the computer). You can examine that intercepted traffic, perhaps in Wireshark or similar, to see where it's bound; if it's not addressed to your proxy port, then the app isn't respecting the proxy settings.

As a side note, Burp supports transparent proxies, and I've used it with apps that disregard proxy settings (usually in combination with DNS spoofing). You have to listen on the port the app is communicating to - probably 443 - though, so you might have to start your proxy with elevated privileges. Of course, if the cert pinning is working correctly, you still won't be able to actually decrypt the intercepted traffic.

Improve this answer
0

This sounds like your instance of Burp may have auto pass-through enabled: https://portswigger.net/blog/ssl-pass-through-in-burp

Check your pass-through settings.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.