For the average user who doesn't understand that there are different corporations governing different TLDs, this is all rather frightening and trust beyond the com/org/net tlds will likely continue to erode. I would have expected ICANN to have thought this through more carefully.
I can only hope that a statement like this isn't used to pacify the masses until this issue is relegated to obscurity. In the mean time, I'm looking at other publishers (thank GOD that many of them I heaven't heard of are discussed here) for content and refuse to pay for a $400/yr safari subscription while NEVER REALLY OWNING ANYTHING.
> their certs are more trustworthy than 90% of the certs that users would add.
Why? Why wouldn't I trust my own cert more than any Google trusted certs. I'm sure the majority of CA's are responsible entities, but I trust my certs more, because I control them!
Exactly! I will absolutely not buy Android N(owned many Android devices so far). Google collects all users activities by default while don't let me trust my own CA, how ironic. I guess Google thinks only itself is trust-able and it has the right to baby seat whoever uses its devices, in the name of protecting its users...No Thanks Big Brother.
This renders tools like mitmproxy un-usable. But really, if it's your device, why can't you see your own traffic?
I can understand how this might improve security, but it locks you out of the conversation your own phone is having. Feels like reverse privacy; Not even you can know what you're saying!
I believe Android is taking this approach because of hawkish network appliances vendors selling all too powerful gear to enterprises and these enterprises don't care about what to decrypt and what not and causing too many weaknesses on the way.
I belive MITM decryption for enterprises is a flawed way of identifying intrusions and doesn't stop or hinder any intrusions. It only provides a false sense of security.
Intruders will always be able to fool appliances by using encapsulation of multiple encryption protocols or using non-standard protocols.
I can't really say if Google is taking this approach to secure a device from heavy handed enterprise admins; but if true, it's gone too far by allowing only the app from having private conversations with the api and not allowing the user to see what's being sent over the wire.
This isn't exactly new, we do after all, have certificate pinning. But now, this certificate pinning is done at the OS level by DEFAULT, un-trusting all certs except the ones that Google deems fit.
We know that there have been un-trustworthy Certificate Authorities that all our machines have trusted until its been deemed unworthy by our vendors... and eventually expunged! But this change explicitly un-trusts us, the users of our own phones -- in the name of security.
User deftnerd (https://news.ycombinator.com/item?id=12061342) had an excellent suggestion that the trusting of user added certs can be relegated to the TPM module (via password, passcode, fingerprint, etc..) -- not by the heavy handed approach of simply blocking us out of our own phones conversation.
This may be a conspiracy theory, but how probable is that this move is instead actually motivated by app developers that want to make reverse-engeneering harder? There have been cases in the past were hidden APIs were discovered that e.g. Twitter or WhatsApp were reserving for their own apps. (Not to mention privacy leaks). This will certainly become harder with the new change.
Honestly, it shouldn't change that too much, since third parties like Cyanogenmod should be able to reverse the change. Of course, it's still a horrible move.
In my experience enterprise MITM decrypt is not usually deployed to identify or stop intrusions. It is deployed to enforce compliance with corporate usage rules and as part of a data loss prevention solution. Quite often these are both necessary to meet regulatory requirements.
MITMing the world won't do anything against data loss.
It might "protect" you against data exposure (though I wouldn't count on it), but that shouldn't be affected by any regulators unless your employees have access to WAY too much user data.
Data loss prevention refers to preventing unauthorized, purposeful or unintentional, access or transmission of sensitive or critical information. A comprehensive DLP solution covers data at rest, data in use and data in motion. Network DLP solutions help address the data in motion. They use MITMing in order to inspect data leaving the enterprise. They are often deployed in order to meet regulatory data protection requirements.
For example, I used to work in investment banking. It was well known, and expected, that us (and probably most other institutions) had network level monitoring, to prevent say, the leaking of a deal on some chat or web forum somewhere. Believe me, when there's lots of money involved, there are plenty of incentives to leak things.
You'd look pretty silly if you had to explain to the regulatory authorities that you took zero steps to secure your network perimeter, or prevent the exfiltration of privileged or confidential data.
And there are other legitimate use cases - educational institutions and schools come to mind.
You still can, it just involves a bit more work: grab the .apk, decompile it, insert your own network-security-config into the manifest XML, repackage and install onto the device.
Xposed can do the same without modifying the apk file in storage, instead it intercepts the calls and modifies the responses for what the app config would be.
There is already kind of a parallel to this - you can't see the raw data that the apps on your phone are storing unless you root the phone. It's all protected under the app's userid that you can't access. The only exception that I know of is for apps built in debug mode.
