Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Changes to Trusted Certificate Authorities in Android Nougat

android-developers.blogspot.com

Post reply on HN
Print view View original

81–90 of 103 posts

Re: Changes to Trusted Certificate Authorities in Android Nougat

#81

Post by gergles »

Qantourisc wrote: post #69
wtbob wrote: post #20

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

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

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.

Re: Changes to Trusted Certificate Authorities in Android Nougat

#82

Post by iancarroll »

michaelt wrote: post #65
Jaruzel wrote: post #32

Earlier quoted context omitted.

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…

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…

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.

Re: Changes to Trusted Certificate Authorities in Android Nougat

#83

Post by gergles »

Spooky23 wrote: post #38

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.

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

Re: Changes to Trusted Certificate Authorities in Android Nougat

#84

Post by mook »

iancarroll wrote: post #82
michaelt wrote: post #65

Earlier quoted context omitted.

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…

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.

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.

Re: Changes to Trusted Certificate Authorities in Android Nougat

#85

Post by tssva »

Nullabillity wrote: post #68
tssva wrote: post #17

Earlier quoted context omitted.

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.

Re: Changes to Trusted Certificate Authorities in Android Nougat

#86

Post by wtbob »

Qantourisc wrote: post #69
wtbob wrote: post #20

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

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

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

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.

Re: Changes to Trusted Certificate Authorities in Android Nougat

#87

Post by tssva »

rtu wrote: post #72
shazow wrote: post #28

Earlier quoted context omitted.

Can you point me to one? Sounds neat.

My favorite is (open source) netguard. It is really easy to use, nice ui, nice default options. I will be super bummed if this will no longer work. 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…

Netguard uses a host file to provide incorrect DNS results to prevent ads and doesn't filter the data, so it doesn't need to install a user CA certificate. This approach while generally effective can't block certain types of ads or tracking data that the other solutions or something like ublock origin in your browser can.

Re: Changes to Trusted Certificate Authorities in Android Nougat

#88

Post by Nullabillity »

tssva wrote: post #85
Nullabillity wrote: post #68

Earlier quoted context omitted.

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

> unauthorized, purposeful or unintentional, access or transmission of sensitive or critical information

So there's no loss of data involved. You still have all the data you had before.

Re: Changes to Trusted Certificate Authorities in Android Nougat

#89

Post by GeneralTspoon »

venomsnake wrote: post #21
cube00 wrote: post #13

Earlier quoted context omitted.

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

root + xposed will make quick fix to enable it.

Seeing as Cert Pinning bypassing doesn't currently work with XPosed on Android versions greater than 4.2.2, I'm not so sure about that.

Might require a more in-depth solution.

Re: Changes to Trusted Certificate Authorities in Android Nougat

#90

Post by GeneralTspoon »

kuschku wrote: post #51
johncolanduoni wrote: post #48

Earlier quoted context omitted.

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.

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

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

Although it only works with Android versions up to 4.2.2, due to limitations of the XPosed framework.

Post reply on HN