I'll give mitmproxy a try. Thanks!
I should be able to see what data an app is sending, and certificate pinning (and ATS according to another comment) kills that. That's not a good thing.
The obligatory related link: https://www.gnu.org/philosophy/right-to-read.en.html
I think some applications use certificate pinning when validating a certificate provided by a default certificate authority, but, if you manually install a root certificate onto your device, the app will accept the override. That's one possible middle ground.
Reverse engineering isn't inherently good or bad, it's just a tool. That tool can be used for both good and bad.
I always recommend certificate pinning in order to prevent MITM attacks. I also recommend it if you're backend API gives out a lot of information about your product's "secret ingredient".
That said - certificate pinning can often be bypassed:
The argument of the European Court of Justice was that car manufacturers also buy cars from competitors, take them apart, and use the gained knowledge on their own products. The same happens in every industry — but in Software Engineering, it should now be forbidden? That's not possible.
If you want to protect yourself from that, publish your secret sauce and patent it.
So I'll happily keep on ignoring those tldrs.
I interpreted this as "Data generated by me on my phone belongs to me."
The user could agree to license her rights to the data, e.g. via terms and conditions. But it's still her data. That's why the agreement is necessary.
None of this has anything to do with "reverse engineering".
The scenario I am thinking of is a user looking at her data being sent from her hardware over an internet connection that she is paying for.
And you can. There are many ways. Something as simple as 2 socat instances and netsed works great as a quick and dirty but very robust solution. See also sslsplit which will generate certificates on the fly.
Anyone who is telling you that you can place complete trust in the use of x509 certificates on the open internet is either naive or dishonest.
I think you have the right attitude.
In terms of protecting users, there's no valid reason the owner of the hardware should not be able to control the list of endpoints that she has already authenticated and is willing to trust.
It would be like if SSH did not allow the user any control over known_hosts or to decide that she will accept or not accept a connection.
So if the user does not want to trust a certificate installed by someone else on the device, she can "revoke" it?
And by the same token if she wants to explicitly trust a certificate, regardless of who installed it, she can do so?
Does the user have control of the process of "trust" or not?
The entire point of the device, OS and apps is to benefit the user, not some third party trying to hide data being sent from the device... from the user.
Do you believe a user should be able to "MITM" her own traffic or not?
I do, but that is utterly irrelevant to this discussion. We are discussing what certificate pinning is and how it works.
You can currently perform certificate pinning on every single operating system you can imagine. You can do this in a way that completely ignores the trust store of that operating system, and anything the user does to this is ignored by the application.
This has been possible for years on Android. This has been possible for years on Windows. This has been possible for years on Linux.
All the developer has to do is include the certificate of their own CA with the application, restrict the SSL's trust store to this one certificate, and then also check the fingerprint of the resulting certificate offered by the server. Then if the application notices this fingerprint is incorrect, it bails.
This is reality. This is how it works. Nothing I believe or want will change this. No amount of certificates I install in my operating system's trust store will change this either.
What android is doing is making MITMing yourself harder. But it's always been 100% possible for developers to make MITMing impossible without first reverse engineering the app and replacing the baked in certificate.
That's just the way it works.
That's not good for users.
I do not rely on Android, Windows or Linux. Not really much an app user either.
But if I were a user of these systems I would avoid apps where the user is not allowed to see what is being sent. Irrespective of any justifications put forth. By a company that relies on collecting personal information and selling advertising to make money.
Yeah, no shit. But that's not my, or your, point. Do you even have a concrete point you're getting at, or is it just "I don't like Google"?
Android is making it MITMing apps harder if the application itself did not attempt to make it hard. It has ALWAYS been possible for applications to pin their certificates and to make MITMnig them a pain in the butt. On every OS. On Windows. On Linux. On Mac. On iOS. And yes, on Android too. It has always been that way. I already went over this. Here, go read this: http://security.stackexchange.com/questions/29988/what-is-ce...
But, there is a solution! One that they (Google) also clearly indicated in the blog post when they announced this whole thing. And that solution is: Install a custom rom which does not have these security features. Bam. Done! That's all it takes. If you care about your privacy you're already running a custom rom. And if you care about MTIMing apps, then installing a custom ROM is not that much of a hurdle either.
There's other OS besides the ones you mentioned. And there's other small form factor computers besides mobile "phones" sold by telecom companies.
If you don't want to use OSes, devices and software that's designed to protect the average user from being hacked, then pick a system which gives you root.
SSL pinned is not an protection for reverse engineering anymore, you may want to add this info on your post.
More info at
I don't think it's FOSS, but hopefully a FOSS alternative will come along and use this approach.
I recommend the experience highly. Just be warned, you may not like what you see.
Disclosure: I'm the developer.
Just a suggestion: I know you mention it in one of the marketing lines, but it might be worth stating that it's for Mac in the headline (or in the download button). Otherwise people like me, who just breeze past the marketing material to the download link, will waste 6.8MB of your bandwidth (sorry about that...)
One terrible idea I just had was creating only one publicly accessible API and then encrypting the actual endpoint in the payload which the server would decrypt and then redirect.
You just reinvented the TLS socket connection.
However, if the phone app uses certificate pinning and SSL it doesn't work. (yes, that means my alarm company doesn't use certificate pinning).