
Changes to Trusted Certificate Authorities in Android Nougat - ffernand
https://android-developers.blogspot.com/2016/07/changes-to-trusted-certificate.html
======
userbinator
...and so it begins...

[https://news.ycombinator.com/item?id=9078741](https://news.ycombinator.com/item?id=9078741)

[https://news.ycombinator.com/item?id=9078762](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.

~~~
digi_owl
I wonder if it is just another symptom of a upswell of paternalism that is
plaguing IT these days.

------
pdkl95
Taking away the user's ability to manage their own security should bring with
it the responsibility - and _liability_ \- for any problems that derive from
the imposed settings.

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.

~~~
mtgx
I very much agree with the liability responsibility and liability argument
that you're raising. I also fully believe self-driving car makers should be
100% responsible for accidents and hacking incidents of their cars and they
should fully compensate the victims of such accidents and hacks.

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.

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

------
ffernand
I first learned about this from the tweet
[https://twitter.com/agl__/status/751184962049576960](https://twitter.com/agl__/status/751184962049576960)

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!_

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

~~~
ffernand
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](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.

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

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

------
tssva
There are several ad blocking solutions for Android which involve creating a
VPN connection which terminates to an app local to the device. This allows the
app to filter all traffic for ads including ads inside apps. These solutions
depend on installing a user CA certificate in order to filter TLS connections.
I wonder how much preventing these type of ad blockers played into this
decision.

~~~
shazow
Can you point me to one? Sounds neat.

~~~
tssva
Google doesn't allow these apps in the play store due to the ability to block
ads in apps. Several can be found in the Amazon app store. Adclear and Adguard
are 2 examples. By utilizing the local VPN to redirect traffic for filtering
these apps are able to work without requiring root access as other ad blocking
solutions on Android do.

~~~
revelation
You can't have ad blocking apps on the Play (god that ridiculous name) store?

~~~
tssva
You can have browser or browser extensions which block ads on the Play store.
Apps which block ads within other apps are not allowed.

------
deftnerd
I would rather see the OS let people load the cert but then require the user
enter their PIN, password, or unlock drawing. Then the cert can be signed by
the PIN/etc and trusted.

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.

~~~
sounds
After reading the article, I think what you describe can easily be implemented
-- at the _app_ level.

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.

~~~
kuschku
And how can I add the CA of my university, for example, which is required for
some university networks?

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.

~~~
x1798DE
Accepting a university cert seems like a terrible idea. I would look into a
mobile hotspot or, even better, transferring to a different university.

[https://security.stackexchange.com/questions/104576/my-
colle...](https://security.stackexchange.com/questions/104576/my-college-is-
forcing-me-to-install-their-ssl-certificate-how-to-protect-my-pri)

~~~
Piskvorrr
Do you trust your university more, or "TÜRKTRUST Elektronik Sertifika"?

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)

~~~
x1798DE
I don't particularly trust either, but:

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.

~~~
kuschku
You do realize a CA can be limited to be trusted only for some things, yet not
for others?

For example, many such university certificates are not trusted as CAs for
HTTPS?

~~~
x1798DE
I was talking about MITM certificates. I don't really understand why a
university is not just getting a certificate from a CA in the trusted store,
but I would have many fewer qualms about something that is not a general MITM
certificate. That said, my experience is that generally applications that have
a legitimate reason for a limited-use self-signed certificate don't need to be
in the general store. For example, it's common to set up OpenVPN with a self-
signed certificate, but I've never had to add a certificate to the general
store for that - it's always app-specific.

------
ingenium
This is a pretty annoying move for anyone who has their own CA they use to
sign internal domains. I wonder if they will also have Chrome not trust
them...

~~~
andrewguenther
Keep in mind, this specifically affects apps. Not necessarily Chrome, which I
would guess is going to use the Trust API to allow them. So unless you have
custom apps that access internal domains, then you shouldn't be impacted at
all.

~~~
kuschku
And how can I force all apps to accept it? I’ll have to end up rooting every
device.

This will just mean that even more will be running rooted, reducing security.

~~~
Natanael_L
Root and Xposed, yes. That's probably going to be the easiest solution.

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.

------
ausjke
Totally against this. Why not leave the choice to the user instead of Google
enforcing this. MITM is good for some purposes, e.g, debugging, enterprise
filtering etc.

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.

~~~
JoshTriplett
> Why not leave the choice to the user instead of Google enforcing this.

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.

~~~
ausjke
1\. Then make some password-protect mechanism instead of taking that choice
away. That's the key issue, that Google is trying to make decisions for its
users because Google may think it knows better.

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.

------
wtbob
This is just terrible news. Android's treatment of user-added certificates is
already terribly broken (why does it warn me that my network connexions may be
monitored when I install my own certificate, when Android already trusts e.g.
Symantec?), and this makes it worse.

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.

~~~
Qantourisc
For in case YOU didn't put the CA on your phone.

~~~
gergles
Right, but you are warned forever* if you have a user-installed CA on your
phone and you go to a site or use an app that uses that cert.

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.

------
mataug
I feel this is a great win in terms of security for the average consumer. Sure
VPN connections within organizations may get affected but the've got a
workaround for that and I'm sure IT at orgs where they have an internal CA can
figure it out.

~~~
Jaruzel
The recommended path for large orgs (one of which I was recently employed at,
and attached to a relevant project), is to:

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.

~~~
michaelt
Are you familiar with any CAs that will issue certs for a few hundred servers
(under the same domain) that aren't on the public internet, with an automation
API and at a reasonable price?

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.

~~~
iancarroll
GlobalSign's CloudSSL will issue certificates with up to (IIRC) 200 SAN
extensions for somewhere around $2k, but wildcard certificates will cover most
use cases at a much lower price point.

~~~
mook
A wildcard is a bad idea here since one compromised host would have a
certificate that works on all other hosts. A better solution would be a sub CA
that's restricted to issuing certificates for that domain only, but name
constraints is an extension that some (obsolete) clients might not handle
correctly.

------
andrewguenther
ITT: People who think the average Android user knows how CAs work and has the
competence to manage them.

For the majority of users, this is a very good decision.

~~~
tokenizerrr
And for the rest there should at least be an option in the hidden developer
menu. Not make it solely up to the app developers.

------
wyldfire
I was going to try writing an addon/extension to chrome to make a visible
warning indicator when this site was trusted only via user added certs. That
would've allowed me to see when my company was intercepting my traffic at the
proxy (the proxy decides not to intercept some sites, mostly ones w/pinned
certs). Unfortunately this info doesn't seem to be available to the framework.
:(

------
zdw
I think this decision should be inverted - user/admin installed CA's should be
trusted by default (but not able to be preloaded, by say a malicious cellphone
employee at a store), but the entire public CA list (aka, "people we expressly
allow to MITM you") should be run in front of and require approval by the
user.

But that's a problem everyone seems comfortable with ignoring...

~~~
chii
a user would not be able to tell whether they can trust a public CA (they
probably have nfi what it is).

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

------
0x0
It's strange to see Android take this extremely anti-local-CA stance, while
Chrome on the desktop does the exact opposite, even bypassing key pinning if a
local CA is in the chain. [https://www.chromium.org/Home/chromium-
security/security-faq...](https://www.chromium.org/Home/chromium-
security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-
and-filters-)

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.

~~~
pfg
The way I understand it, this only affects apps, not Chrome for Android.

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.

[1]:
[https://tools.ietf.org/html/rfc7469#section-2.6](https://tools.ietf.org/html/rfc7469#section-2.6)

------
616c
And here I was thinking a fun first project would be a socat client with self-
signed certs for remote access.

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.

~~~
andrewguenther
I'd say their certs are more trustworthy than 90% of the certs that users
would add. This is a pretty no brainer security move on Android's part.

~~~
ffernand
> 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!

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

------
Spooky23
Android has always been wonky about private PKI. One of the big initial
reasons why a past employer went all iOS.

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.

~~~
gergles
Apple has global proxy support but only over Wi-Fi. Cellular requires a VPN.

------
aviraldg
What options does this leave for me if I do want to monitor traffic from apps
on my device?

------
wfunction
Can this be bypassed with root access? (Note: stuff like patching binaries in
memory doesn't count... I mean something that's reasonably simple for users to
do, like editing a config file or something.)

~~~
userbinator
_Note: stuff like patching binaries in memory doesn 't count... I mean
something that's reasonably simple for users to do, like editing a config file
or something_

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

------
mrb
Previous submission (did not receive many upvotes though):
[https://news.ycombinator.com/item?id=12052618](https://news.ycombinator.com/item?id=12052618)

------
malka
Time to switch to iOS then

------
ex3ndr
I suppose this is answer of Google for all governments that forces people to
install Government CAs on their phones.

------
cocotino
Goodbye to using Fiddler easily to check out the private HTTP API of any app
that does not implement cert pinning

~~~
cube00
What are the options to inspect this traffic now we can no longer use fiddler?

~~~
andrewguenther
If you're trying to debug your own app, there are ways to turn this off for
debugging.

~~~
kuschku
And if you want to use your legal right to reverse the functionality and APIs
of other apps?

~~~
johncolanduoni
If your device isn't rooted, modify the APK to opt-in and don't share it with
anyone.

If your device is rooted, just add your cert to the system store.

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

~~~
GeneralTspoon
If you plan on doing that, it might be worth looking into a similar project
that uses the XPosed framework to bypass certificate pinning at a low level:

[https://github.com/iSECPartners/Android-SSL-
TrustKiller](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.

------
rasz_pl
That phone you are holding? It is not your property, you are the commodity
being sold. Same is coming to Browsers with EME.

