Changes to Trusted Certificate Authorities in Android Nougat
android-developers.blogspot.com
android-developers.blogspot.com
https://news.ycombinator.com/item?id=9078741
https://news.ycombinator.com/item?id=9078762
I am not exactly surprised, but it is very sad to see, because what happens on locked-down mobile platforms, desktops seem to follow sooner or later. You can argue that power users and developers will always find ways around it, but what this does is effectively remove one more little bit of that freedom which lets users discover what their devices are actually doing, and I think that is a very bad thing in the long term.
Much of my knowledge about how computers work in various ways has been gained through exploring creatively and inspecting what things do. I use a MITM proxy on my PC that blocks ads, tracking, and rewrites webpages to my preference. I learned a lot of HTTP, HTML, and CSS just from doing that. But maybe that is exactly what those in power do not want --- users who can think and investigate things for themselves --- because such users are not easy to control.
The paternalistic attitude that users are and always will be ignorant is not only offensive. it is counterproductive. Security is not a product, and keeping people ignorant of the trust models they are relying on is a recipe for disaster in the long-term.
Instead of pretending that users are always going to be ignorant of security and incapable of learning, the UI should be extended to make the chain-of-trust more visible in a way that helps the users understand their security situation.
Instead of pretending that one security model fits all situations, more control needs to be given and taught to the user, in a way that actually allows them to make decisions about their security situation.
However, I think this is generally a good thing. When Android has 50 different OEMs (or whatever the number is), then some standardization is a good thing for the user.
You don't want Samsung or Huawei or some local Turkish OEM, or perhaps even the retailers themselves (as we've often seen with malware on imported Chinese phones) to start loading up certificates in a device before selling it. Think about what Lenovo and Dell, or all the anti-virus companies, are doing with their own certificates to PC users because Windows allows people to install their own certificates.
Also, in some countries, such as Kazakhstan, they want to start requiring users to download the "national security certificate" and install it in their devices.
This policy would prevent all of those things. That doesn't mean we still won't see CNNIC and Blue Coat/Symantec and other untrustworthy certificates loaded up by default in all Android devices (which you can still disable yourself), but I think overall this is still a good move from Google.
I'm ok with this. Even if I can't add a custom root certificate, I would like the ability to distrust any root certificate I explicitly do not like. That coupled with standardization of certificates loaded by default makes this sound like a welcome change.
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 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.
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.
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.
So there's no loss of data involved. You still have all the data you had before.
Data loss is an accepted term to describe what tssva is talking about - and yes, it is a real thing in the real world - e.g.:
https://en.wikipedia.org/wiki/Data_loss_prevention_software
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.
I guess I was was wondering how Google would resolve the conflict between their basic function -- making money by serving ads -- with a user experience which is almost always improved by blocking ads.
Mobile chrome will never have extensions, excuses side, because Google had the opportunity with a new platform and new browser to make sure ad blocking wasn't as easy as installing an extension.
I personally run mobile Firefox with ublock origin. Wonder if that will be always be possible?
If I need to root my phone to get a system level VPN / firewall / adblocker, I might as well just get an iPhone and jailbreak.
So, I don't think so.
This would allow certs to be added, but prevent them from being silently side-loaded by an admin or malware. Changing your PIN would invalidate the cert but you could just be prompted to resign them.
So the app opts in?
Seems strange to me. What you're suggesting makes a lot more sense.
The big change is that Android no longer provides an ability to add a CA for all apps on the device ("device global CA"). There is only one "global CA store" now, the one shipped with Android.
Device updates can update the CA store, and the article talks about how to get your CA included.
Especially because it has to be in the global store?
Or how am I supposed to use my legal right to reverse and understand the functionality and APIs of software I have installed?
EDIT (as I can’t create new comments for the next hour): The certificate is not used for HTTPS – but for TLS for IMAP, for example, and for some internal services, eduroam, etc. Obviously, that means that the Email-App needs to use the cert, too, in addition to the Android system, and a bunch of other apps.
https://security.stackexchange.com/questions/104576/my-colle...
ca.mit.edu
Who is that, you ask? That is precisely my point. I have no idea, none at all. I do happen to know what my university was (and why it was running its own CA). Yet, this one is doubleplusgood for me. Trust Google, it knows best.
(I went to my Android's builtin trusted CA list, this was the very first one - out of a list of about 100, or maybe 200)
1. The university is explicitly asking to MITM your traffic, so that's an automatic no-go on any of my devices for me. At least other CAs will be punished if caught.
2. I'm fairly certain these university certs are not subject to certificate transparency, and even if they were, since they are explicitly designed to MITM traffic, I'm not sure that it would raise any red flags if someone other than the university was issuing these certs for inappropriate domains. At least TÜRKTRUST Elektronik Sertifika issuing inappropriate certificates are much more likely to get caught doing anything fishy (with high profile sites, anyway).
3. What you're really trusting is the vendor of whatever security gateway, not the university itself. If you look at the Security.SE thread I linked, there was an actual issue with at least one of the black box vendors. I don't think the other vendors are considerably better.
So, all-in-all, I would not accept an MITM certificate on any device that I used for anything personal, full stop.
For example, many such university certificates are not trusted as CAs for HTTPS?
Once the university (and their providers) have modified their apps to opt in, the user sees a net benefit. I guess it might be hilariously optimistic to expect the university and all of their providers to actually fix their software, but that's the other way of looking at that specific problem.
Others are using GMail, or AOSP mail, etc.
You can’t seriously expect every single Android app to add the feature back, do you?
And even then, I still get no benefit – I have to update my own fork of AOSP mail, too, I have to update a bunch of system apps, I can’t use eduroam properly anymore, and I can’t MitM the traffic of my own device anymore. The only thing this does is my life worse.
Every single Android update since KitKat has done that. Made my life worse. Removed features, killed AOSP stuff, moved code into proprietary apps, and prevent people from modifying their own device.
This will just mean that even more will be running rooted, reducing security.
Root doesn't inherently reduce security - it only adds as much target surface as you chose to add. Adding root services with bugs is dangerous, but one-off tasks with secure code and a secure root manager isn't a problem.
While google collects all my info by default these days, what's wrong to let me install my CA locally myself? Google is becoming an online policeman more and more these days.
I now hope Firefox OS or Ubuntu Phone OS prevails. Also I'm hoping there is a strong google search competitor soon. I no longer favor Google, though it's difficult to find an alternative at this point.
Because often the choice isn't made by the user.
> MITM is good for some purposes, e.g, debugging
The linked page documents how to enable custom CA certificates for debugging. If you're trying to debug an app that doesn't want to be debugged, you're probably running a custom rooted version of Android anyway.
> enterprise filtering
Which the user should be explicitly aware of if it's happening.
2. OK thanks.
3. That is a corporate policy issue, it can state all corporate network is monitored and it installed a local CA etc. Without a local CA all https sites will pop up warnings and it leads to more problems. By the way corporate normally tunnels a safe list of https sites without doing any MITM, such as banks, well known "good" websites etc.
What they should have done was gone the other direction entirely. If I — the owner of the phone — choose to trust a certificate authority, then every app should obey me, without complaint or warning. It's my phone, not Google's.
At some point, it should recognize that you've continued using the cert XX times or for XX days or both and stop trying to guilt you into removing it via the use of some illusory 'you might be insecure' bogeyman, when Symantec, an already 'trusted' CA, could issue any cert for any site and you'd have no recourse or ability to tell if they should have.
Everyone 'might be insecure', that's just how it works.
*Maybe this goes away at some point months down the line, but it's at least 30 days and has to be some number in the 1000s of uses if the warning eventually quenches.
How can anyone but me install a CA on my phone?
And with this change, even I can't install a new CA on my phone such that applications will use it. That's no good at all.
1. Ensure all internal domains can also be registered externally (although the actual external registration step is optional), but this means no more .local or .companyname type TLDs internally.
2. Use an external CA to provide your certs, for both internal and external use.
Obviously, this means a bit of pain[1] for existing non-standard internal domains, but with the big shift to cloud, this is less of an issue going forward.
Also, external CAs will no longer provide you with a cert for internal domains that are not also able to be registered externally.
--
[1]Massively understating this, of course.
Lets Encrypt isn't an option, because (a) the servers aren't on the public internet and (b) even if they were, LE is limited to 20 certificates per domain per week.
I'm aware that Plex has some sort of deal like that, but is that a one-off thing, and if it's something any company can get in on, how expensive is it?
I know some CAs offer 'enterprise services' but their websites don't seem to spell out what that means or what it costs - just that you should contact them to schedule a demo, which probably means the costs are eye-watering.
For the majority of users, this is a very good decision.
But that's a problem everyone seems comfortable with ignoring...
A user installed CA is more likely done by an automated mean (such as a jail break, or malware) than the user themselves. This choice means they can at least stop some malware/crapware. Yes, the legitimate users with self installed CA got screwed over, but in google's eyes, those people are going to put up with it, because they've already invested in the android platform (and won't switch to iphone).
Especially so since Android since 5.x already shows a huge obnoxious "Your network may be monitored" if you have installed a local CA.
It's a shame you can't configure certain domains to ONLY trust a specific LOCAL CA system-wide. It would completely eliminate the security problem that is untrustworthy or hacked global CAs, for example for your own/enterprise mail server.
Chrome on desktop follows the HPKP RFC on this matter[1]. Failing pins that chain up to local CAs would break many deployments. On mobile, apps that implement certificate pinning are usually already broken if a MitM proxy is used, so it's a different context and this move improves the situation for apps that haven't moved to cert pinning yet (it's not a full replacement as it only helps with the "malicious local CA" problem).
The implications of an attacker being able to import a CA certificate are different on mobile as well, IMO. On desktop, this usually implies administrative access, in which case anything Chrome could do would be pointless, as the attacker could also just replace/modify binaries, install a keylogger, etc. Android has a more fine-grained permission system, and an attacker who tricks a user into installing a CA certificate would not necessarily be able to do these things, so this would definitely make things harder for them.
The more I want to learn about smart phone development and ecosystem, the more offputting it gets by the year.
But yeah, use our PlayApp Store we can better track you in real time. OUR certs are WITHOUT DOUBT TRUSTWORTHY.
Sometimes I feel neckbeards will beat us youngbloods to death for the sins we let pass.
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!
Apple also lacked (I haven't look in detail in awhile, so ymmv) a global proxy capability, requiring stupid solutions like GRE tunneling or mandatory VPN.
Adding your own certs to the system store in /system will make it fully trusted.
Sites that use pinning won't work anyway.
If you write an app for it, that'll make it simple for users. (And then no doubt you'll get a bunch of "security" people complaining that your app is malware...)
Might require a more in-depth solution.
If your device is rooted, just add your cert to the system store.
So, basically the same as before, but there’s no UI for it anymore?
Fuck this.
I might just modify the Java SSL libs on Android to even accept my cert when cert pinning is used, if I have to spend that much effort anyway.
I get that the intention is to make the device more secure but Google's execution on this is disappointing and lazy, and the result is that my devices no longer trust me the owner, which I don't consider acceptable given the lack of liability.
I'm curious what Apple's response will be.
https://github.com/iSECPartners/Android-SSL-TrustKiller
Although it only works with Android versions up to 4.2.2, due to limitations of the XPosed framework.