Charles Proxy now available on iOS

Post by 220V_USKettle » Wed, Mar 28, 2018, 10:25 AM UTC

simcop2387 wrote: post #35

yodon wrote: post #34

Genuine question here: How is it not absolutely terrifying that an iOS App Store app can man in the middle HTTPS communications made by other apps? Is there some way in which this isn’t poking a hole in exactly the sort of security sandbox that iOS tends to be good at? (And yes there probably is some part of what’s going on that I don’t understand, that’s why I’m asking the question)

Can't say much about the security, but I suspect it's working by pretending to be a VPN provider and then proxying the traffic. It's then able to install a CA root to generate any certs it needs to MITM traffic. Cert pinning will prevent this from working, but that's the only thing that will.

Post by tzahola » Wed, Mar 28, 2018, 11:11 AM UTC

220V_USKettle wrote: post #81

simcop2387 wrote: post #35

Earlier quoted context omitted.

Can't say much about the security, but I suspect it's working by pretending to be a VPN provider and then proxying the traffic. It's then able to install a CA root to generate any certs it needs to MITM traffic. Cert pinning will prevent this from working, but that's the only thing that will.

Do iOS apps not require cert pinning by default for their respective APIs/whitelisted https domains?

Post by mavhc » Wed, Mar 28, 2018, 11:14 AM UTC

yodon wrote: post #38

simcop2387 wrote: post #35

Earlier quoted context omitted.

Can't say much about the security, but I suspect it's working by pretending to be a VPN provider and then proxying the traffic. It's then able to install a CA root to generate any certs it needs to MITM traffic. Cert pinning will prevent this from working, but that's the only thing that will.

Supposed sandboxing against malicious apps is precisely why I run iOS rather than Android. I get that Charles isn’t malicious, but what’s keeping any random free game app from doing the same thing? (Again, intended as a real question not a rhetorical one)

Post by rem1313 » Wed, Mar 28, 2018, 11:49 AM UTC

miles wrote: post #24

This is awesome! The first thing I discovered was how much network noise crashlytics.com was causing. Used AdBlock's[0] DNS proxy feature to black-hole the offending domain (they even mention blocking crashlytics.com in their FAQ[1]). Note that both AdBlock and Charlex rely on iOS's VPN feature, and only one can be enabled at a time. [0] https://itunes.apple.com/us/app/adblock/id691121579?mt=8http... [1] https://www.…

Post by rimliu » Wed, Mar 28, 2018, 12:19 PM UTC

majewsky wrote: post #72

rimliu wrote: post #36

Earlier quoted context omitted.

And the desktop version allows to intercept the traffic of the machine it runs on. Mitmproxy cannot do that afaik.

What do you mean? This has been working since way before 1.0.

  > 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.