Changes to Trusted Certificate Authorities in Android Nougat • Hacker News Board

Re: Changes to Trusted Certificate Authorities in Android Nougat

#31

Post by kuschku » Sat, Jul 09, 2016, 3:23 PM UTC

sounds wrote: post #11

deftnerd wrote: post #3

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.

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.

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.

Re: Changes to Trusted Certificate Authorities in Android Nougat

#32

Post by Jaruzel » Sat, Jul 09, 2016, 3:23 PM UTC

mataug wrote: post #12

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.

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.

Re: Changes to Trusted Certificate Authorities in Android Nougat

#33

Post by kuschku » Sat, Jul 09, 2016, 3:25 PM UTC

andrewguenther wrote: post #19

ingenium wrote: post #6

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

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.

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.

Re: Changes to Trusted Certificate Authorities in Android Nougat

#34

Post by maxerickson » Sat, Jul 09, 2016, 3:25 PM UTC

616c wrote: post #8

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.

Why would this impact that? Apps can still use whatever certs they want, they just won't automatically pick up certs that are added at the system level.

Re: Changes to Trusted Certificate Authorities in Android Nougat

#35

Post by kuschku » Sat, Jul 09, 2016, 3:25 PM UTC

andrewguenther wrote: post #25

cube00 wrote: post #13

Earlier quoted context omitted.

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

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

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

Re: Changes to Trusted Certificate Authorities in Android Nougat

#36

Post by ffernand » Sat, Jul 09, 2016, 3:26 PM UTC

andrewguenther wrote: post #24

616c wrote: post #8

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.

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.

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

Re: Changes to Trusted Certificate Authorities in Android Nougat

#37

Post by ianlevesque » Sat, Jul 09, 2016, 3:31 PM UTC

cube00 wrote: post #13

cocotino wrote: post #5

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

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

Modify the APK first to add certificates or disable the pinning.

Re: Changes to Trusted Certificate Authorities in Android Nougat

#38

Post by Spooky23 » Sat, Jul 09, 2016, 3:31 PM UTC

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.

Re: Changes to Trusted Certificate Authorities in Android Nougat

#39

Post by x1798DE » Sat, Jul 09, 2016, 3:31 PM UTC

kuschku wrote: post #31

sounds wrote: post #11

Earlier quoted context omitted.

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.

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 f…

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

Re: Changes to Trusted Certificate Authorities in Android Nougat

#40

Post by pdkl95 » Sat, Jul 09, 2016, 3:32 PM UTC

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.