Note that both AdBlock and Charlex rely on iOS's VPN feature, and only one can be enabled at a time.
- Prompt to allow app to act like VPN
- Having to enter your passcode after said prompt
It's impossible for apps to MITM silently.
I know that without it we wouldn't have amazing apps like https://itunes.apple.com/us/app/adblock/id691121579 , but i'm really not sure if its worth that risk for a common user that apple mostly targets with iOS.
Not sure about the current state though.
Charles desktop app is well respected in the developer community. There is no reason that the iOS app will be treated any differently.
2. You have to trust the Charlesproxy root certificate; again, in the system settings.
You can also click a link to a certificate on a webpage and install it manually on iOS.
How exactly does one go about patching the binary – is there a tutorial somewhere?
>How exactly does one go about patching the binary – is there a tutorial somewhere?
There are guides you can google for cracking apps and replacing the certs they compare against. IIRC they all require a jailbroken device.
 Of course you can use the blanket NSAllowsArbitraryLoads to allow plain HTTP everywhere.
Under what conditions does iOS allow an app to do this?
The fact that Android has recently made it impossible to MITM apps is really making me consider switching. I don't think I will, because in many other ways Android is still more open, but the analysis is no longer as lopsidedly in Android's favour.
I turned it on for literally one second and the first thing it captured was traffic from an app I used briefly several years ago and not since. Cool!
Charles could show a list of recommended apps to delete.
But something like "Little Snitch for iOS" would fit the bill.
I generally would only be needing to inspect requests when developing at my workstation, so how is this native app providing additional value beyond what the Charles Mac software already provides?
Big fan of Charles over here, I just don't understand the use case for the native app.
"Running Charles on your iOS device means you no longer need to fiddle with WiFi network proxy settings. It also means that you can capture and measure network traffic that goes over the Mobile / Cellular data network.
Measuring networking performance over Mobile data is especially important for your mobile apps (as that is how a lot of users experience your app), and it can reveal large or slow requests, as well as opportunities to increase perceived performance by parallelising network calls."
AFAIK before this you could only inspect traffic over WiFi connections since you had to set the proxy address via WiFi network settings.
I can't use Charles to inspect traffic from my device at work because of network restrictions. Now I can.
Using the Mac app also requires being able to connect to your Mac from your iPhone (in order to use it as a proxy), which is not doable on many setups. For example, at work we use a different wifi network for mobile devices than we do for laptops.
You can watch his presentation  (which is linked to in the announcement page that story links to) for a few of the use cases.
I guess it's mostly used if the application is doing something critical like money transactions etc.
It seems like you need a jailbroken device, and that there are tools such as SSL Kill Switch
For instance if a CA gives a CA certificate to a government running an SSL inspection service.
It re-encrypts the traffic using its own SSL certificate (technically a CA, but no need to get bogged down in details).
In many modern apps, code has been added such that an app will only accept traffic which has been encrypted by the original server certificate (ie: the Uber iOS app will only accept traffic which has been encrypted by a certificate from www.uber.com). When Charles attempts to sit between this traffic, the app will not allow network connections, and thus no traffic can be inspected by Charles.
This procedure of an app only permitting traffic encrypted by a predefined certificate is known as "certificate pinning" or "pinning" for short. It is becoming more and more common for native apps.
(Yes, this is a still-trying-to-fix-it real world event... Glad it's not my problem, just one I hear about from people I used to work with...)
All developers should get this for iOS, it’s bound to be useful and if not it will at least be interesting to see what you’d phone is getting up to online!
Anyone else have this issue?
The website isn't giving me much insight :(
edit: I'm on the latest iOS beta. Could that be why? funny that I'm troubleshooting an app which is largely meant for troubleshooting apps...
Yeah it works once I disable it, kind of an important pointer the app could alert users to...
I was originally thinking that maybe the MITM VPN IP clashes with my LAN subnet.
Be sure that your default proxy port doesn't conflict with the default WSS port.
Edit: for reference I'm on Charles 4.2.1
> Note that the rdr rules in the pf.conf given above
> only apply to inbound traffic. This means that
> they will NOT redirect traffic coming from the box
> running pf itself. We can’t distinguish between an
> outbound connection from a non-mitmproxy app, and
> an outbound connection from mitmproxy itself - if
> you want to intercept your OSX traffic, you should
> use an external host to run mitmproxy. Nonetheless,
> pf is flexible to cater for a range of creative
> possibilities, like intercepting traffic emanating
> from VMs. See the pf.conf man page for more.
However I'll continue to use wireshark for debugging my network code when at the office.
Then she uses this phone with the custom kernel (phone #1) as a gateway for another phone (phone #2). She can easily block ads and other undesired traffic destined for phone #2, using a variety of methods of her choosing (firewalls, dns, proxies, etc.).
She does not use phone #1 for anything other than being a gateway for phone #2. There does not have to be any data of any value to an advertiser generated, sent from, or stored on phone #1 (e.g, logs). It is just a gateway.
Cant do this, but imagine if she could.
Also I used the term "destined" but just to be clear I meant both ingress and egress traffic.
If she were able to use Android as gateway for iPhone on same subnet, "sett[ing] up a [third party server] in a cloud" is precisely what she would be trying to avoid.