[HN Gopher] Android 14 blocks all modification of system certifi...
___________________________________________________________________
Android 14 blocks all modification of system certificates, even as
root?
Author : pimterry
Score : 294 points
Date : 2023-09-05 13:42 UTC (9 hours ago)
(HTM) web link (httptoolkit.com)
(TXT) w3m dump (httptoolkit.com)
| CSDude wrote:
| HTTP Toolkit was very helpful for me to extract hidden APIs from
| crappy EV charging apps in Turkey, combined with Frida to prevent
| SSL pinning and root detection.
|
| Then I realized, the reason they try to hide is maybe those APIs
| are abomination /s
| 1vuio0pswjnm7 wrote:
| Where are the diffs of Android 13 against 14. Isn't this an "open
| source" project.
|
| If Google actively prevents "rollback" to a previous version,
| then how does a computer owner try out the new version. Once
| installed, there is no going back. Even if the owner discovers
| the new version is unsuitable. It's Amazon with no returns. A new
| car without a test drive.
|
| Reading source changes might be an easier way to review the new
| version than running it in an emulator and trying to figure out
| what changed. Is it not possible.
| varispeed wrote:
| Obviously governments can't have an operating system where users
| can do as they please, e.g. bypassing government mandated MITM
| certificates so they can spy on citizens.
|
| So the groundwork is being prepared for coming things like Online
| Safety Bill here in the UK, where all communication will likely
| be under surveillance and so you won't be able to mod your phone
| to "opt out".
|
| It's a shame that such resourceful company like Google bends over
| to some control-freak right wing governments like we have.
| LocalH wrote:
| > It's a shame that such resourceful company like Google bends
| over to some control-freak right wing governments like we have.
|
| Why wouldn't they? They obviously see an opportunity to grab
| even more control over the Internet than they already have.
| SpaghettiCthulu wrote:
| Do you consider the Democrats right-wing? How about the CCP?
| Authoritarian, sure, but there is authoritarianism on both ends
| of the political spectrum.
| cumshitpiss wrote:
| American democrats would be considered right wing in other
| nations e.g. europe
| surajrmal wrote:
| It's strange that you jump straight to thinking the government
| is involved. Moving most system components to be updatable
| independently of the core os is a good thing. Google should be
| taking these steps. Not being able to update apex files makes
| sense as any update will quickly overwrite your changes.
|
| This change just moves the bar for modification to be
| controlling the remote update source. I'm sure it will still be
| possible to alter that and therefore gain control. This would
| be similar to how you handle DNS.
| jeroenhd wrote:
| Kazakhstan actually tried a government mandated CA certificate.
| It's causing constant "you are being watched" notifications on
| phones that loaded the certificate. Certificate security was
| increased in Andeoid and other opeeating systemsm exactly
| because of this threat.
|
| Every OS except Android receives regular CA updates, including
| them various Linuxes. Android devices are still trusting known
| bad actors like Startcom exactly because there's no way to
| update just the CA store (and cheap Chinese brands definitely
| won't release full system updates for this after dropping
| support a year after the phone came out).
|
| You can disable the toggle for every system CA in your phone's
| settings if you want. That is, unless you think the big bad UK
| government bugged your phone to hide the CA that's been planted
| there, but if that's part of your threat model, the government
| certificate may be hidden on your phone already
| ylyn wrote:
| Isn't this just how mounts work? If you have a something mounted
| to /apex/whatever and each app has a separate mount namespace,
| then mounting over /apex/whatever in your namespace wouldn't
| change anything in any other mount namespace. You'd need to
| either just alter the filesystem directly, or enter the other
| apps' mount namespaces and mount your tmpfs there too.
|
| Shared mounts might be useful here. Not sure. I'd need to take a
| closer look at what is going on here.
|
| But I would say this result is probably a byproduct of whatever
| namespacing/containerisation Google is doing, rather than an
| intentional effort to prevent users from changing the root CAs
| even as root.
| pseg134 wrote:
| [flagged]
| pimterry wrote:
| > But I would say this result is probably a byproduct of
| whatever namespacing/containerisation Google is doing, rather
| than an intentional effort to prevent users from changing the
| root CAs even as root.
|
| Yes, I think in practice that's true. The end result is still a
| big problem though!
|
| > Isn't this just how mounts work? If you have a something
| mounted to /apex/whatever and each app has a separate mount
| namespace, then mounting over /apex/whatever in your namespace
| wouldn't change anything in any other mount namespace.
|
| The latter 'separate mount namespace' here is the surprising
| bit. Previously, you could open a shell, mount things into the
| filesystem (or just modify it directly) and apps would happily
| read files from those mounts.
|
| Now, for these cacert files, that's not the case, and
| additionally with the new approach direct modification is
| impossible.
|
| Before this change, I wasn't even aware that Android apps were
| using their own mount namespaces! There's very little
| documentation on exactly how that works and I'm not sure if
| there's been a case where its been clearly visible until now.
| auveair wrote:
| > But I would say this result is probably a byproduct of
| whatever namespacing/containerisation Google is doing, rather
| than an intentional effort to prevent users from changing the
| root CAs even as root.
|
| Technology is very convenient when it's complex enough to find
| an excuse to fit your business objective (see manifest v3).
| curiousgal wrote:
| I mean if they were willing to mess with something that was
| completely unbroken like the quick access tiles for WiFi/data
| back in Android 11 (or was it 12?) I wouldn't put it past them to
| mess with anything else.
| kevincox wrote:
| Android isn't really open. In order to have a "certified" device
| you need to remove user control. For example users by default
| aren't even allowed to access app's "private" data. That was
| enough to get me to move to something where I am in control.
|
| But if you move away from a "certified" ROM then you start to
| fail SafetyNet (or its successors) and many apps will refuse to
| work. Those apps want to make sure that the user isn't in control
| of their devices, they want to make sure Google or a "trusted
| party" is.
|
| They say this is to ensure the security of your device that logs
| into your bank or whatever, but I guarantee that my LineageOS
| updated this week is more secure than my stock Google ROM that
| got its last update 3 years ago. If Google really wanted to prove
| security with SafetyNet they would stop attesting devices that
| haven't been updated. But it isn't about device security, it is
| about ensuring that the device is controlled by a big
| corporation, not the user.
| charcircuit wrote:
| >In order to have a "certified" device you need to remove user
| control.
|
| No, you don't.
|
| >For example users by default aren't even allowed to access
| app's "private" data.
|
| Which is already what Android's security model specifies. It
| means that other apps or other people using your phone won't be
| able to steal data like your 2FA app's private key.
|
| >Those apps want to make sure that the user isn't in control of
| their devices, they want to make sure Google or a "trusted
| party" is.
|
| Their app may benefit, or even rely on the android security
| model. Unverified devices have the possibility of having that
| security model broken.
|
| >If Google really wanted to prove security with SafetyNet they
| would stop attesting devices that haven't been updated
|
| I agree, but there is a trade off where you will cut out old
| devices. This is why at first Google lets app developers choose
| if they want to avoid devices that can just be spoofed.
| zb3 wrote:
| > Which is already what Android's security model specifies.
|
| Which means removing user control over that data.
|
| > Unverified devices have the possibility of having that
| security model broken.
|
| Again, this "security model" implies removing user control.
| The apps protect user's data from that user..
| charcircuit wrote:
| No user control is being removed. The data was managed by
| the app by design.
|
| There is no way for the phone to know who owns the device,
| nor would it be able to know that when ownership is
| transferred to not show sensitive information to the new
| owner.
| feanaro wrote:
| Let's not pretend to be daft. The user can prove
| ownership by providing a PIN. They can also delete their
| data before transferring ownership to a new owner. (Not
| to touch at all upon the fact that selling devices is
| really uncommon to begin with.)
|
| Nothing about any of that requires the user to cede
| control of their own device as a "solution".
| surajrmal wrote:
| Security depends on your threat model. Your threat model and
| Googles are not aligned. They are protecting against threats
| you are happy to ignore or otherwise have other counter
| measures for. I think the real problem is assuming a one size
| fits all strategy works for everyone.
| varispeed wrote:
| This banking apps requirement is laughable if you can manage
| you bank accounts through the internet browser. I mean there
| are some banks that only work with an app, but majority of
| banks in my country work through the browser just fine.
|
| That being said, I have a separate phone just for bank apps and
| turn it on only when I need to use it for banking.
| bitsandboots wrote:
| I've always thought so too - who is banking on their phone?
|
| And, loans aside, if I had money in a bank that forced me to
| change the way I live my life just to store money, I would
| move to a different bank and tell them that's why they lost a
| customer.
| izacus wrote:
| > I've always thought so too - who is banking on their
| phone?
|
| Most people these days.
| ianburrell wrote:
| Have you never needed to transfer money when traveling or
| out of houseIf US, have you ever mobile deposited a check?
| If rest of world, have you ever sent money?
|
| I use bank web site most of the time. But if not at home,
| it is really useful to use phone. It isn't like banking is
| complicated that need computer and browser. Bank web sites
| tend to be awful on smaller screens, I don't use it on
| iPad. Also, there are a lot of people that only have phone.
| bitsandboots wrote:
| > Have you never needed to transfer money when traveling
| or out of house
|
| No? It can wait for me to return home. Before wireless
| internet existed this wasn't an issue, so how has that
| changed things?
|
| > If US, have you ever mobile deposited a check?
|
| I admit this was literally the only time I used banking
| apps, but nobody uses checks anymore. I haven't needed to
| do this in years.
|
| > If rest of world, have you ever sent money?
|
| Yup, paypal website. Don't even need the app. Works
| better than venmo etc because it works internationally
| and various competitors that are app-only only work in 1
| country anyway.
| seized wrote:
| ... Who isn't banking on their phone? That's how I do it
| 90% of the time.
| zb3 wrote:
| > This banking apps requirement is laughable if you can
| manage you bank accounts through the internet browser. I mean
| there are some banks that only work with an app, but majority
| of banks in my country work through the browser just fine.
|
| Well, that's exacly why Google has proposed WEI - to make
| sure they no longer do, and the user is practically forced to
| have a device that has bundled Google spyware.
| Izkata wrote:
| > WEI
|
| Link so people don't need to go looking:
| https://news.ycombinator.com/item?id=36875940
| kevincox wrote:
| Yeah, I have switched to a bank that is accessible via the
| web. But I fear that eventually they will all require an app.
| ajross wrote:
| > They say this is to ensure the security of your device that
| logs into your bank or whatever, but I guarantee that my
| LineageOS updated this week is more secure than my stock Google
| ROM that got its last update 3 years ago
|
| Those are two _entirely_ different threat models. The second
| clause of your sentence is about vulnerability to exploits,
| something that Lineage or other ROMs are at least better
| positioned to do than a vendor that has EOLed the device
| (though the amount of binary junk required by those distros
| puts a pretty firm cap on that promise -- they can only fix
| what they can patch!).
|
| The first clause talks about the need for back end service
| providers to be sure that no entity is interposted between them
| and their users/customers. It's a desire that no extra app can
| sit there and sniff interaction or prompt for
| passwords/tokens/secrets/etc... Third party open ROMs not only
| fail to address this need, they actively hurt. You can
| trivially make a "We're Totally Your Bank We Swear" app and
| deploy it to a LineageOS phone that steals the money from any
| account that authenticates with it.
|
| Is that a "good" security model or a "bad" one? There are
| arguments to be had. But prompt application of bug patches
| isn't one of them.
| tomatocracy wrote:
| There are some ridiculous examples of apps refusing to run on
| rooted devices or custom ROMs. The Heathrow airport app, for
| example - why does an app which just shows me flight times and
| maps care at all?!
| izacus wrote:
| You want the honest answer?
|
| Because security consultants slapped that on some checklist
| and Heathrow will now bugger contractors that build Android
| app to implement root checks.
|
| Enterprise apps are full of this bs. I partially blame Google
| because it made checking for integrity so easy that every app
| owner now things it needs to use it.
| OfSanguineFire wrote:
| If an app shows maps, it usually won't run on a ROM like
| LineageOS that lacks Google Play Services. This is because
| the API that app developers overwhelmingly use to show maps
| is the Play Services one, not the vanilla AOSP one. (I'm not
| even sure if AOSP has a map API.)
|
| LineageOS with MicroG will run some of these apps and show a
| map using OpenStreetMap tiles provided by MapBox, but the
| functionality may still be broken because the MicroG's maps
| support is not a full replacement.
| tomatocracy wrote:
| In this case this isn't about lack of Play Services maps
| etc - the app looks for root and refuses to run if it sees
| it.
| [deleted]
| m3adow wrote:
| > That was enough to get me to move to something where I am in
| control.
|
| What smartphone OS are you referring to? Sounds interesting.
| kevincox wrote:
| LineageOS with root enabled.
| bitsandboots wrote:
| That gives you some control, but because lineage is mostly
| just using upstream android, and google's "contributions"
| to AOSP continue the overall decline of android, and the
| majority of apps adhere to google's behavioral demands of
| the play store, even lineageOS gets worse every year by way
| of it not being a hard fork of what was once a good OS.
|
| Not that I have a solution to the problem. Just saying the
| current and foreseeable future state is that smartphones
| are past their glory days, and the platform defeated
| itself.
| kevincox wrote:
| It is definitely not perfect. But having root does allow
| you to do most of what I want to do.
|
| Unfortunately to participate in modern society you
| basically need iOS or Android, and iOS is far worse for
| user freedom. So I have taken the best option I could.
|
| I also help "with my wallet" by preferring websites for
| everything that has no need to be an app. But I am sure
| that I am the minority.
| tkems wrote:
| In my opinion SafetyNet is no longer about security and is
| mainly DRM at this point. I think you are right on the money
| about the out of date devices too. I was going through my Dad's
| old phone collection this weekend and noticed that several old
| Android phones have specs that are not terrible today but are
| not useable due to no updates from the OEM. So now they are
| mostly e-waste. These are perfectly useable phones (maybe
| outside of an old battery) for basic tasks.
| r0b1n wrote:
| SafetyNet was always about DRM. The Play Store contains tons
| of malware despite SafetyNet, and malware does malware things
| despite SafetyNet.
|
| Also, SafetyNet makes alternatives to Google Cloud e.g. for
| Backups non-viable, so win-win for Google I guess.
| kevincox wrote:
| You are confusing SafetyNet with Play Protect. Play Protect
| is about protecting devices from malware. SafetyNet is
| about protecting services from "untrusted" devices. It is a
| remote attestation API that validates that the device is
| running a "trusted" operating system.
| bboygravity wrote:
| What backups? It's literally impossible to take backup
| images of an Android phone (as in: the entire thing, not
| just some Playstore apps and some of the settings).
|
| The last phone I used that supported taking a backup image
| of the entire phone was a 2013 BlackberryOS 10 device.
| r0b1n wrote:
| You cannot even backup all of the playstore apps, tons
| and tons set the magic "don't backup" bit.
|
| You are totally right in that there are basically no
| useful backups on android whatsoever. The closest thing
| is "adb backup" when you have root and developer settings
| enabled, which is saying a lot.
| summm wrote:
| Even Firefox does this. Because of something something
| security.
| bootlooped wrote:
| That makes so much sense. Back when I had a rooted device, I
| was once blocked from using... the Instant Pot app. Yes, a
| recipe app. It gave me a message saying something vague about
| security.
| bonyt wrote:
| I think android is - and has been - more heavy-handed than Apple
| here. Even when you could install and trust a new root CA, some
| apps can and would ignore this. Apps can use certificate pinning
| on both iOS and Android, but apps by default on Android just
| ignore user-added CAs by default on Android 7+, since 2016[1].
|
| On iOS, the process of trusting a root CA is (rightfully) tricky,
| requiring you to install a profile and jump through some hoops
| with some scary warnings, but in my experience most apps will
| trust it unless they're using pinning.
|
| [1]: https://android-developers.googleblog.com/2016/07/changes-
| to...
| moelf wrote:
| huh, but on iOS you have apps that can ignore your VPN
| connection... https://restoreprivacy.com/latest-ios-found-to-
| bypass-vpn-co...
| jeroenhd wrote:
| The same is true on Android for processes with system
| capabilities/root, I believe, because they can bind sockets
| to a specific interface and bypass the VPN you use.
| jeroenhd wrote:
| I can honestly see why Google did this in Android 7. Android,
| being much closer to a normal computer than iOS, has a huge
| stalkerware problem. Stalkerware isn't stopped by prompts,
| weaponises backwards compatibility, and includes all manner of
| abuse.
|
| On iOS it's shockingly easy to subvert your HTTPS privacy for
| years after you've let someone borrow your phone for five
| minutes.
|
| I would love the option to actually trust CA certificates I
| install (especially Firefox, a fucking web browser, doesn't
| even opt into user certificates without a secret tap combo and
| hidden settings), but I don't think this feature is important
| enough for the dozens of techies using them day to day
| considering the risk to every other Android user on the planet.
|
| In this case there's no evil Google conspiracy to thwart the
| plans of your local IT department, this is just a side effect
| of Google's excellent sandboxing improvement and long overdue
| CA store update mechanism.
|
| I'm sure Magisk modules will appear to work around this
| problem. The existing Magisk modules will be broken for a while
| but that's par for the course after major Android updates. I'll
| write a module myself if I have to.
| soraminazuki wrote:
| First, this is utterly false:
|
| > On iOS it's shockingly easy to subvert your HTTPS privacy
| for years after you've let someone borrow your phone for five
| minutes.
|
| You need a passcode to install certificates. And people
| casually handing over their phones would be a much bigger
| problem if that really is widespread behavior.
|
| Second, can we stop using "techies" as some kind of magic
| word to make any technical concerns go away?
| vetinari wrote:
| > especially Firefox, a fucking web browser, doesn't even opt
| into user certificates without a secret tap combo and hidden
| settings
|
| Firefox uses it's own CA store and installing your own is
| trivial. Ever tried to just open URL with your cert? The ui
| for certs isn't nice, but you can still view them in
| 'about:certificate'
|
| Installing into system store and then configuring Firefox to
| use system store is the hard way, on all supported systems.
| jeroenhd wrote:
| > Firefox uses it's own CA store and installing your own is
| trivial. Ever tried to just open URL with your cert? The ui
| for certs isn't nice, but you can still view them in
| 'about:certificate'
|
| Not on Firefox for Android, it just makes me download the
| file. You can do it of course; just go to Settings > About
| Firefox > Tap the Firefox logo seven times > Go back >
| Secret Settings > Toggle "Use third party CA certificates".
|
| about:certificate shows me a bunch of buttons to export
| certificates, but there's no disabling or importing from
| that screen.
| bitsandboots wrote:
| So many good comments here, but I keep thinking about how
| thankful I am that PCs don't work like smartphones, and it's sad
| it's regressed to this point.
|
| Android has so thoroughly defeated itself, that I feel crazy to
| say I'm thankful that microsoft doesn't run the PC world like
| google runs the smartphone world.
|
| Windows itself is a bastion of stability and sanity compared to
| android. Things do not need to be upgraded prior to the hardware
| actually breaking of old age.
|
| Beyond that, just like google, microsoft doesnt control the
| entire hardware-software pipeline. But just like google,
| microsoft is in a place of power where they could have made it
| incredibly inconvenient to own your PC, by dictating norms
| through a store, or discouraging any deviation of environment by
| safetynet.
|
| My memory is bad here, but did this sort of thing ever end in
| antitrust lawsuits for microsoft in the past? And, when can we
| look forward to the same for google?
| vetinari wrote:
| Microsoft tried, they just failed. For now. They are still
| trying. Windows 11 requires TPM and Secure Boot.
| sumuyuda wrote:
| I think they were successful in obsoleting a huge amount of
| functioning computers, forcing my people to buy new hardware
| to run Windows 11.
| vetinari wrote:
| For now, most people and businesses ignore Windows 11; they
| are happy with Windows 10. In 2025, once the Windows 10
| support ends, it will be more interesting.
| bitsandboots wrote:
| And this is part of my point: by the time microsoft kills
| old computers, if they even do, they'll be 10 years old,
| not 2 years old.
| Xeamek wrote:
| Lets talk when You will have to go out of your way to even
| get access to privileged account in Windows. Right now
| comparing restrictions of TPM to android having majority of
| their api (and functionallity) gated is just laughable
| vetinari wrote:
| Let me remind you Windows RT for ARM. Same restrictions of
| TPM, some screws tightened somewhat more.
| Xeamek wrote:
| >Same restrictions of TPM, some screws tightened somewhat
| more
|
| Well yes, that windows was basically a direct competition
| to android (or tried to). Not sure what has TPM to do
| with anything really, but regardless;
|
| I am not saying that Microsoft is pure hearted angel that
| would never dare to restrict client's freedom. Obviously
| they did it before many times and certainly will in the
| future.
|
| What I am saying though, is that for now, Android is on
| completely different plane of user restriction then
| Windows (in it's main version) is. And even if Windows is
| constantly looking for opportunities to tigthen it's
| grip, none of the restrictions that are implemented right
| now can justify the conclusion, as if Windows is becoming
| so restrictive that it's reasonable to compare it to
| Android. Criticize them all you want, I will as well. But
| let's not bend the reality just so it's easier to say
| 'all corpos bad', rather then putting a small ammount of
| effort to distinguish between the levels of opression
| DistractionRect wrote:
| It's a super soft requirement. I have secure boot and tpm
| disabled on my pc and win 11 doesn't care.
|
| Why? Because I can't set my prefered GPU with uefi enabled
| (which is required for secure boot), and I occasionally
| passthrough my windows disk to a VM when I'm dual booted into
| my Linux OS (so naturally windows can't use the tpm).
| sangnoir wrote:
| People forget that Microsoft tried to go the iOS route and
| control everything by signing everything from boot to
| executables which one would only get from the Microsoft app
| store. This is what spooked Valve into developing Steam
| Machines and Steam OS; I'm grateful for Proton, but it was
| necessitated by Microsoft aggressively closed designs.
| Vogtinator wrote:
| "S Mode" is still a thing. On top of what you listed it
| also enforces Edge as browser and Bing as search engine.
| I'm not kidding: https://support.microsoft.com/en-
| us/windows/windows-10-and-w...
| Joeri wrote:
| S mode is like an ad-funded tier of a streaming service:
| you pay less up-front, but you are forced to watch more
| ads. Herding people to edge and bing is how microsoft
| makes sure they can present those ads.
| Gigachad wrote:
| I can kind of see how this could be a win for users though.
| I've heard that some 3rd world countries demand users to
| install the country CA so they can MitM all connections. By
| making this very hard, it becomes unfeasible to get users to
| disable their privacy.
| jeroenhd wrote:
| Windows has had regular CA updates for about two decade now. If
| anything, Android works more like Windows at this point.
|
| Microsoft has also added tons of DRM to Windows (which they
| later broke). Remote attestation is built into the OS as well.
|
| Google has inconvenienced Android developers by altering the
| Android internals you weren't supposed to rely on anyway;
| Microsoft does this all the time as well.
|
| We may need to wait a few weeks for an updated Magisk module.
| Honestly, it's really notm that bad. Just don't click the
| update button on the five or six devices that will receive
| Android 14 before then.
| chc4 wrote:
| I mean, you still have root and APEX packages aren't doing
| anything tricky specifically to stymie modifications - they're
| just mounted file systems. You're still going to be able to
| modify system certificates, it's just going to be less convenient
| and need something more than dropping a single file to a folder.
| Hell, the code is even still falling back to the old file system
| path if the APEX mount doesn't exist, so you could just delete
| the entire module and go back to the old method.
| pimterry wrote:
| > Hell, the code is even still falling back to the old file
| system path if the APEX mount doesn't exist, so you could just
| delete the entire module and go back to the old method.
|
| That's covered in the article - no, you can't do this. If you
| entirely unmount the apex module from the filesystem from a
| root shell, so the CA certificates aren't visible anywhere on
| the filesystem, apps will still read them successfully. And the
| OS blocks RW mounting of APEX modules so you can't delete the
| cacerts directory within the module either.
|
| It looks like apps have separate namespaced mounts, managed by
| the OS itself from boot. Effectively they're containerized, and
| as part of launching all applications the OS is mounting the
| certs directly into the process's view of the world.
|
| If you can find a way to modify the filesystem the apps see
| from a root shell, that would be great! I'd love to hear about
| it. But believe me that I've tried quite a few of the obvious
| things already.
| chc4 wrote:
| APEX namespace membership is managed by the ld.txt config
| file for the dynamic linker, iirc. You can probably just
| remove the com.android.conscrypt line, or remove the entire
| conscrypt APEX package from the system and unpack the libs
| into /system/lib64 instead. Or patch the linker not check
| APEX signatures, and repack it without the CA folder. Or
| unmount the conscrypt APEX mount and replace it with a FUSE
| mount that proxies everything else the CA folder. Or...a
| bunch of different other methods.
| MishaalRahman wrote:
| Left a reply to the author on Twitter, but putting it here as
| well in case they didn't see it.
|
| Hi! I'm the guy who wrote the blog post about updatable certs in
| Android 14 that your article linked. Not sure if you're aware,
| but there's actually a system property you can set to bypass
| reading from the APEX cert directory.
|
| system.certs.enabled=true
|
| From: https://android-
| review.googlesource.com/c/platform/framework...
| pimterry wrote:
| I don't think that helps much unfortunately. That's a
| java.lang.System property (i.e. a config value set within one
| JVM/app) as opposed to an android.os.SystemProperties OS
| property (globally configurable on the device via adb).
| Reconfiguring the former requires modifying the app itself
| AFAICT.
|
| That's useful for automated testing (which appears to be why
| they've added it) or for toggling settings between debug/prod
| builds, but not so much if you want to globally trust a CA
| certificate on your device. Of course, if you know a way to
| externally set such a property so that it applies to every app,
| that would indeed work great, and I'd love to hear about it!
|
| (I'm the author btw, and I don't see any such reply on Twitter?
| Classic 2023 Twitter ofc)
| Brian_K_White wrote:
| And recently there were discussions about browsers disallowing
| self-signed certs, even for local host, and going https-only, and
| the supposed excuse is you can edit your local root store.
|
| Well now what?
| nottorp wrote:
| This sounds nice for security, hell for some developers but:
|
| What happens in 2-3 years when this version of Android is
| abandoned? You pray the hardcoded certificates will last you a
| couple more years?
| jakub_g wrote:
| It's been a long known issue [0] that cert providers had to
| account for, but apparently not anymore [1] from Android 14
|
| > Android 14 makes root certificates updatable via Google Play
|
| > Android's root store used to require an OTA update to add or
| remove root certificates. That won't be the case in Android 14.
|
| TIL there's a workaround though [0]:
|
| > If you use Android 7.0 or earlier, you may need to take
| action to ensure you can still access websites secured by Let's
| Encrypt certificates. We recommend installing and using Firefox
| Mobile, which uses its own trust store instead of the Android
| OS trust store, and therefore trusts ISRG Root X1.
|
| [0] https://letsencrypt.org/2023/07/10/cross-sign-
| expiration.htm...
|
| [1] https://www.xda-developers.com/android-14-root-
| certificates-...
| cosmojg wrote:
| Good ol' Firefox, keeping up its reputation as the only user-
| respecting major browser.
| jmholla wrote:
| > What happens in 2-3 years when this version of Android is
| abandoned?
|
| I had to install a Let's Encrypt certificate to get my self-
| hosted password manager working because Google's updates are
| missing an intermediate certificate Let's Encrypt uses. This is
| not a hypothetical down the road issue but an issue present
| right now. Why should Google be the final arbiter of who I
| trust? They clearly have their gaps.
|
| And let's not even get started on the existing approved
| certificate providers that you shouldn't really be trusting
| since they've been shown to provide certificates to people and
| organizations that shouldn't have them.
| izacus wrote:
| Certificates are an APEX module now (which is the crux of
| authors complaints actually), which means they're updated out
| of band by Play Services and don't need an OS update from OEM.
| arusahni wrote:
| They're updatable via Google Play starting with 14, so not tied
| to OS updates.
| nottorp wrote:
| But google will abandon this Android version fairly soon as
| we all know... what Google Play updates in 6 years?
| jeroenhd wrote:
| Google still updates the built-in for Android 7. They don't
| really abandon device support for old OS versions like iOS
| tends to.
|
| The current situation is that the CA bundle doesn't receive
| any updates from Google. If your manufacturer repackages
| their CA bundle and still updates your device, you'll
| receive a new CA bundle, but I don't believe this is
| guaranteed.
|
| Furthermore, if you're still running Android 14 after six
| years, your issue is with the manufacturer of your device.
| The latest version of the CA bundle will still work of
| course, but you should really be at least four or five
| Android versions higher at that point.
| arusahni wrote:
| Google already guarantees Pixel security updates for 5
| years, so I'd say that's at least the baseline. When Google
| removed Play Services support for the 4.x series they were
| 9 years old at that point.
| nottorp wrote:
| Google and guarantees in the same sentence?
|
| https://arstechnica.com/gadgets/2023/08/google-kills-two-
| yea...
|
| Random example that even has pixel in it. Not to mention
| the other randomly canceled services.
| arusahni wrote:
| /shrug you do you.
| idiotsecant wrote:
| Objective achieved : consumer buys new phone.
| looperhacks wrote:
| My wife just had to replace her phone because of that. Apps
| generally don't accept user certificates and the first apps
| stopped working because Google cloud (or something related)
| updated to a newer certificate
| phh wrote:
| As an author of an old root for Android, and of a modern generic
| custom ROMs, and other Android OS stuff:
|
| The title is, and forever will be wrong. When we say you're root
| in Android, you're actually root. You can actually do whatever
| you want [1]. Magisk (the now modern "root" for Android) now
| includes stuff to even "edit" Java code, so even if it's hidden
| deep somewhere, you should still be able to access it. (Even if
| somehow it moves from Java to native code, we'll still find ways,
| don't worry)
|
| The fact that the author didn't manage to do it doesn't mean it's
| not possible. I could guess what's the author issue (I have two
| ideas in mind: 1. it requires stop;start to restart zygote,
| because zygote cached CAs, 2. it needs to switch to correct mount
| namespace before doing the commands), but I won't try it, I got
| tired of working on closed-source Android stuff.
|
| > More investigation is required and it's hard to know the full
| implications of that now, but for the many forks of Android like
| GrapheneOS & LineageOS, and for advanced device configuration
| tools like Magisk and its many modules, it probably spells
| trouble.
|
| I just don't understand this. GrapheneOS and LineageOS team have
| full source-code access. They can do whatever they please with
| it. (The limitation being that Google breaks stuff at an
| incredible rate, and following is a bit annoying)
|
| Anyway, I hope that Android becoming more and more user-hostile
| (and more specifically in this case power-user-hostile) will move
| more and more people to custom ROMs. (In my dreams I make a
| "OwnerDroid", an Android fork where the security model doesn't
| have the first line saying "the user is an enemy", but even
| though I developed some tiny bricks of it, the overall project
| would take a huge amount of work)
|
| [1] Except for some kernel-level protections, but GKI reduces
| that risk.
| SenAnder wrote:
| > The limitation being that Google breaks stuff at an
| incredible rate, and following is a bit annoying
|
| That's a strategy to keep the competition busy just keeping up:
| https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
|
| If you ask "what competition (from Android forks)?", that means
| it's working.
| DistractionRect wrote:
| Armchairing here, but from a quick gloss over the article it
| seems like it should be quite easy to stub out:
|
| > this new approach reads certificates from
| /apex/com.android.conscrypt/cacerts, when it exists.
|
| Much like the how the current work arounds for safetynet,
| hiding root, and hiding magisk work, it should be possible to
| hide /apex/com.android.conscrypt/cacerts from select processes
| as needed to make it fail over to the old way.
| wink wrote:
| > Anyway, I hope that Android becoming more and more user-
| hostile (and more specifically in this case power-user-hostile)
| will move more and more people to custom ROMs.
|
| What about people who kinda gave up tinkering with custom ROMs
| because the state of the stuff that matters (root checks by
| your mandatory banking app, some Google stuff) is either not
| documented (good luck finding an overlap of "phone model" +
| "your local bank app" + custom ROM" as a tested and known-good
| thing).
|
| I'm all for freedom and choice, but I don't think unless you're
| willing to go through a couple of phones, a couple of days of
| work, or are a specialist in the first place, this is a
| reasonable way of action for average phone users. I know you
| said "power users", but I'm a power user with computers, my
| phones could be a lot dumber if I had my way - but it won't
| happen if we have to increasingly use them as MFA devices or be
| at the whim of corporations with a better lever (i.e. banks,
| I'm not changing my bank account 3 times until I find one with
| an app that works on a rooted phone...)
| nilespotter wrote:
| Just use the bank's PWA, you'll be fine. Or sandboxed play
| services in a separate GOS user.
| vetinari wrote:
| It is different issue than that.
|
| European banks are forced by EU's Payment Services
| Directive 2 (PSD2) to authenticate using MFA for any
| payment over 50 EUR.
|
| So what is the second factor? Your phone. Once you pair the
| app in your phone with your account, you can authenticate
| your actions using that phone, even if you are otherwise
| banking using the web app on your computer. Most banks also
| insist on using their apps, they don't allow generic second
| factors. Since their apps require Android with SafeNet or
| iOS, they pretty much enforce the Google/Apple duopoly.
|
| For now, there are other ways -- sms, which the banks are
| trying to phase out.
|
| So I imagine situation elsewhere will be very similar.
| daef wrote:
| I don't know where you're from, but here in austria most
| banks offer 'cardTAN' as an alternative to mobileTAN. I
| always assumed cardTAN is a thing everywhere...
|
| edit: with cardTAN you get a OTP/TAN 'calculator' into
| which you put your smartcard to generate TANs on the fly.
|
| I use it because to me this feels more like a real second
| factor, when I use my mobile for banking.
| vetinari wrote:
| The DACH world is specific in many things... but I've
| seen cardTAN outside it. In Slovakia, Tatra banka does
| use this system. I guess being part of Raiffeisen
| explains it.
| 4ad wrote:
| cardTAN is being rapidly phased out in Austria.
| wink wrote:
| Fun fact, I still have the thing here, used it for many
| years, but they made it obsolete. App only now. It's a
| German Sparkasse :(
| jacquesm wrote:
| Same here in NL, for now. But: banks are pushing their
| apps hard, to the point where every authentication you
| have to manually switch - again - to indicate that you
| want to use the token generator and _not_ their app
| (never mind cookies and so on, those are only for the
| marketing department, when for once they could actually
| use them to store your preferences).
|
| And there will likely be a time when the bank simply cuts
| access to the cardTAN system and only allow their apps.
| Screw them because that means I _have_ to use a
| smartphone, which I really do not want. The cardTAN
| system has been very good so far in preventing fraud,
| once the phone is the token it suddenly gets a lot more
| complicated and less secure.
| nilespotter wrote:
| > Since their apps require Android with SafeNet or iOS,
| they pretty much enforce the Google/Apple duopoly.
|
| That is positively insane. So if you don't use vanilla
| Android or iOS, you can't use a credit card for more than
| 50EUR? No phone, dumb phone, too bad?
| liotier wrote:
| My French bank, CIC, sold me a Digipass scanner+pin
| authentication device. Adding yet another device to the
| usual kit bag won't make it very popular but an option
| independent from Google/Apple exists and I guess that its
| non-existence wouldn't fly for long with regulatory
| authorities.
|
| https://www.onespan.com/products/transaction-
| signing/cronto/...
| kaliszad wrote:
| Banks have no clue about 2FA/ MFA, they will happily put
| the bank app and the custom TOTP generator/ "key"-app on
| the same phone or, as a fallback, send SMS to the same
| phone the bank app is on. So in reality, it's at best
| 1.5FA because when the phone is owned, the user already
| lost. And it is really hard to not have the banking app
| on the phone with many institutions. Some institutions
| now put the TOTP generation into the same app too. Oh and
| there are limits on the user name and password-length
| that make it easier for attackers to crack, in some cases
| (in Germany) the password can be exactly 5 characters
| long and the username tends to be the debit card number
| by default. In many ways, this is really cumbersome, not
| really secure and on top of everything else adding a
| false sense of security. Less advanced customers are
| either somewhat secure but then the product is barely
| usable or they can realistically use the service but the
| security is so-so.
| wkat4242 wrote:
| My bank wants me to type a code received in the app into
| a number field a little bit lower on the screen in the
| same app. They consider this a second factor. Of course
| it's nothing but busywork and security theater.
| usrusr wrote:
| They do? My bank is very explicit about "don't ever run
| the front-end and the second factor on the same device".
| Perhaps it's a German thing, with all our Datenschutz
| fundamentalism that will happily consider even IP
| addresses PII?
| vladvasiliu wrote:
| > Banks have no clue about 2FA/ MFA, they will happily
| put the bank app and the custom TOTP generator/ "key"-app
| on the same phone or, as a fallback, send SMS to the same
| phone the bank app is on.
|
| This. My bank in France, BNP, does that. Every so often,
| when I connect to the app on the phone, it says something
| similar to "in accordance with <some regulation> a strong
| authentication must be made every <number> of sign-ins".
| You're presented with only one button that says something
| like "ok". You press it, and you're in business.
|
| This is after requiring me to type in my pin, which must
| be precisely 6 digits, and some sequences are forbidden,
| so you can't type 1234 or similar. It doesn't seem to
| interact with the secure enclave in any way.
|
| If this number of sign-ins is reached while I'm on a PC
| (which is the most likely), it'll send a confirmation
| request on the phone, so at least it works there. When
| paying online, I'll also get a confirmation request on
| the phone app.
|
| On my professional account, with the same bank, the
| situation used to be exactly the same. But a few months
| ago, they switched away from that to sending a
| confirmation code via SMS for bank transfers. Credit card
| payments still have the app confirmation request.
| threeseed wrote:
| > Banks have no clue about 2FA/ MFA
|
| Of course they do. But they need to balance security with
| end user experience.
|
| And since security for a bank is about risk management
| they can offset this risk in other areas to compensate
| e.g. additional processes for activities involving larger
| amounts of money.
| Izkata wrote:
| > Just use the bank's PWA, you'll be fine.
|
| Just over a month ago, a proposal to prevent that was
| posted here: https://news.ycombinator.com/item?id=36875940
| bob1029 wrote:
| The authors of the PWAs would need to opt-in to this.
|
| We distribute LOB banking apps as PWAs to our customers.
| In no reality would I consider incorporating this into
| our tech stack. We use PWAs and avoid native apps
| precisely to maximize compatibility across arbitrary IT
| policies in our various customer installs.
|
| I don't know if our customers want to use linux, windows,
| android or apple. I don't _WANT_ to know anymore. I just
| want to target a common API (HTML5), add some bandaids
| for iOS /Safari (usually after WWDC each year) and move
| on with life. Throwing DRM and platform constraints into
| the mix sounds like I might as well go back to native (I
| won't).
|
| We are one of the few vendors that will actually get into
| a heated argument and push back against customers over
| FUD security crap like this. If a prospect insists that
| we add some draconian DRM to our product stack, I would
| make it very clear to leadership that I do not think we
| should do business with that customer on technical
| grounds.
|
| If you find yourself in a situation where you need to
| trust the client _implicitly_ , then you have
| catastrophically failed in the rest of your design.
| jabroni_salad wrote:
| I appreciate what you do if you really do deliver that,
| but plenty of FIs are happy to mandate things like
| Trusteer Rapport and I would anticipate that sector to
| jump onto WEI just as fast as media companies will. It's
| going to be sold to execs as a zero operational cost
| lightswitch solution to preventing account hijacks.
|
| Up until about a year ago one major core provider had
| been using the password 'money' for all their client
| accounts, many of which were domain admins since that is
| a 'just make it work' button and they cannot actually
| tell you what privs their service accounts need. When we
| asked the clients to press them on it, we determined via
| cracking that they had changed it to 'monet' as a
| workaround. The standards for excellence are SO LOW.
| bob1029 wrote:
| > that they had changed it to 'monet' as a workaround
|
| > The standards for excellence are SO LOW.
|
| I'm 99% sure I know which vendor you are referring to.
|
| Almost everything in fintech is a hacky mess. This is our
| competitive advantage. Doing the barest-acceptable thing
| makes us look like rockstars compared to every other
| vendor in the space.
| aftbit wrote:
| Outside of the USA, some banks require mobile apps. If you
| don't have a working attested phone in these countries,
| banking becomes decidedly 20th century.
| benabbottnz wrote:
| The two things that stopped me from using custom Android
| ROMs:
|
| 1. Discovered that emergency calls would crash the phone
| (during an emergency)
|
| 2. The LineageOS April Fools prank.
| pierat wrote:
| Presumably as an April Fools' joke, LineageOS added an
| undismissable notification informing users that, "You might
| be a victim of software counterfeiting"
|
| Removing it requires updating to another build or rebooting
| into recovery and changing a setting using terminal via
| setprop .
|
| instructions: Okay I finally managed to solve the LineageOS
| Settings"You might be a victim of counterfeiting" april
| fools joke. Here are the steps to how I solved it 1. Boot
| in to TWRP-recovery 2. Open Terminal under the advanced tap
| 3. Type the following "setprop persist.lineage.nofool true"
| in the terminal 4. Reboot the phone and voila :)
| bayindirh wrote:
| 3. You can't use trusted SIM services such as e-signature
| with custom ROMs. I have an e-signature embedded into the
| cryptographic module of my SIM card, and no custom ROM can
| use that, because they can't provide a secure pipe from SIM
| to antenna, and that's a deal breaker.
| thot_experiment wrote:
| Magisk and Shamiko together have been working well for me to
| hide root from Google Pay/my bank app for the past year or so
| (fingers crossed, ymmv). Highly recommend the experience of
| having a rooted phone though, it's a nice feeling controlling
| your device, especially being able to control the traffic and
| just like... run unix utilities natively. I really wish it
| was something I didn't have to spend so much effort achieving
| but it has been worth it. I find the experience of using a
| device I don't have full control over beyond irritating.
| pimterry wrote:
| The crux is that previously any user could modify these certs
| directly, even on vanilla OS images from Google themselves,
| without installing any tools at all - just by writing to disk -
| and that's both widely used and included in the setup guides
| for lots & lots of tools.
|
| Now, you can't do that.
|
| Of course, with full source code access anything is _possible_.
| You can absolutely build your own Android system images from
| scratch disabling all these modules to work around this, and
| it's certainly possible for GrapheneOS/LineageOS to handle that
| too - but it will create a bunch of new work, and diverging
| from Android's implementations of core components may mean more
| work in future. And for most affected users "first, build your
| own system image" is significantly beyond their comfort zone
| and level of time commitment.
|
| There will be other solutions eventually - it may be possible
| by digging through the namespacing and modifying the mounts of
| target processes individually to disable this, or there might
| be a way to somehow build & install your own APEX modules in a
| way that Android will trust, to replace the system module and
| thereby modify this directory, or who knows what else. There
| will certainly be per-process fixes possible with Frida, with
| hooks targeted to individual applications. More ideas welcome
| too :-D
|
| Despite all that though, it's still going to be a major problem
| that makes it harder for users to fully control their own
| devices.
| izacus wrote:
| > The crux is that previously any user could modify these
| certs directly, even on vanilla OS images from Google
| themselves, without installing any tools at all - just by
| writing to disk - and that's both widely used and included in
| the setup guides for lots & lots of tools.
|
| Yes, and that was used for some horrifying security/privacy
| breaches that made this whole site preach about buying
| iPhones.
| j5155 wrote:
| If I understand correctly, system certificates can be
| modified without jailbreak or any root access on iPhones.
| threeseed wrote:
| You can add new root certificates which is common for
| phones used in the enterprise.
|
| But not aware that you can modify the core root
| certificates.
| unethical_ban wrote:
| Modifying system certificates is uncommon for the average
| user, but for techies and enterprise apps I imagine it's a
| lot _more_ common.
|
| It's one thing for the OS to put dangerous things behind
| warnings, flags and prompts. It is another to cripple the
| OS.
| jeroenhd wrote:
| You can install root certificates, though, and they'll
| work on almost any app you could need in the enterprise.
| WeylandYutani wrote:
| This site preaches iPhone because they make money from the
| Apple ecosystem.
|
| Developers hate piracy, ad blocking and most of all users.
| dang wrote:
| Could you please stop posting unsubstantive comments and
| flamebait? You've unfortunately been doing it repeatedly.
| It's not what this site is for, and destroys what it is
| for.
|
| If you wouldn't mind reviewing
| https://news.ycombinator.com/newsguidelines.html and
| taking the intended spirit of the site more to heart,
| we'd be grateful.
| diegoperini wrote:
| > I hope that Android becoming more and more user-hostile (and
| more specifically in this case power-user-hostile) will move
| more and more people to custom ROMs.
|
| I 100% share your desire but this is wishful thinking imo.
| People tend to comply when given no other options.
| moffkalast wrote:
| So to sum up: skill issue.
| jacquesm wrote:
| Sorry for your experience and thank you for all the work you
| did in this domain. But I'm afraid that custom roms will never
| be a mainstream thing no matter how much Google (or Apple)
| misbehaves. That's a hackers only thing and then only a very
| small fraction of the hackers.
| pjmlp wrote:
| Anything that isn't on standard Android that any non technical
| person uses, doesn't count, as that isn't what regular public
| uses.
| squarefoot wrote:
| > Anyway, I hope that Android becoming more and more user-
| hostile (and more specifically in this case power-user-hostile)
| will move more and more people to custom ROMs.
|
| Or even ditch closed platforms for good. In other words: "Oh,
| PinePhone 2, where art thou?"
| ASinclair wrote:
| If you can modify an init.rc then you can bind mount over the
| apex mount before the Zygote runs.
| phh wrote:
| init could chose to launch every process in a new mount
| namespace, which would break this. I have no idea whether it
| does that, it probably doesn't, but my point is that as long
| as it's not released and open source, it's not worth looking
| at.
| tux3 wrote:
| Even if you can look at the open-source code, it's still a
| maintenance nightmare to try to build on top of it, it just
| moves too fast.
|
| Much like any user could fork Chrome in principle and
| scratch their particular itch, but the sheer pain makes
| that not worth it except for motivated, organized teams
|
| I'm not sure reverse-engineering some Java bytecode is even
| the rate-limiting step at this point, I'm more demotivated
| by the knowledge that everything will break again with
| energy-sapping frequency
| ASinclair wrote:
| I'm in the unfortunate position that I'm in this
| maintenance nightmare at work. Though I solved this
| specific issue months ago. There will be many like it to
| come.
| rollcat wrote:
| > Anyway, I hope that Android becoming more and more user-
| hostile (and more specifically in this case power-user-hostile)
| will move more and more people to custom ROMs.
|
| Indeed, Android 5.0 has been that release for me. The redesign
| left the UI in a state of inconsistent mess, took away dark
| mode, made my otherwise perfectly performant Nexus 4 sluggish,
| broke apps...
|
| Custom ROMs were unfortunately not the answer, at least not for
| me - and TBH I doubt less technical users will appreciate the
| trade-offs. I've tried SailfishOS, been on Cyanongen/Lineage
| for a while, but ultimately if you want a device that just
| works, and works well...
|
| Everything is a compromise, might as well choose Apple.
| pmontra wrote:
| > Android becoming more and more user-hostile (and more
| specifically in this case power-user-hostile) will move more
| and more people to custom ROMs
|
| I never owned a phone supported by any of the custom ROMs I
| investigated.
|
| Samsung Galaxy S2, Sony Xperia X Compact, Samsung A40.
|
| Except the first one, which was huge by the time and tiny
| nowadays, I buy the smallest phone I can find. Apparently no
| ROM developer is interested in those phones.
| NoZebra120vClip wrote:
| I'm not sure of the implications here, so, two questions:
|
| (1) What effect does this have on user-installed credentials,
| such as a certificate for OpenVPN? I used to be able to install
| those myself, with a few taps. They did produce the ominous
| message about someone monitoring my network activity, of course.
|
| (2) Will users still be able to disable CAs in preferences? I
| routinely go through the list of CAs and disable anything I don't
| trust, mainly based on country of origin, so China, Russia,
| Turkey get shut off, et. al. Will this functionality still be
| available in Android 14?
| redleader55 wrote:
| There are several ways[1] for an Android app to trust a CA:
|
| - by default, using the system installed CAs
|
| - if specified in the app manifest, it can trust the user
| installed CAs
|
| - included with the app, also in the manifest, it can trust any
| CA the author of the app decided to trust
|
| [1] https://developer.android.com/training/articles/security-
| con...
| pimterry wrote:
| 1. No effect, as far as I can tell. User-installed credentials
| for other cases are unchanged, this just affects system-managed
| CA certificates
|
| 2. Yes - you can still manually soft-remove CAs through the
| Settings UI
| t0bia_s wrote:
| How green and sustainable this approach from Google exactly is
| when it makes forks like LineageOS harder to maintain?
|
| LineageOS is only way how to keep many devices up to date by
| security patches. Ability to have newer version of Android is
| just a bonus... or... uh wait.
| ZeWaren wrote:
| I have a private PKI I use to connect to my self-hosted software:
| email server, calendar provider, notes server, photo sync tool,
| etc.
|
| I NEED to be able to add my root cert to the list of certified
| authorities.
|
| I don't need to change anything to the system provided list. I
| just need to add mine. It's my device, I'd like to be able to
| change anything if I want to.
| gh02t wrote:
| Same for me, but don't a lot of corporate IT policies deploy
| root certificates to devices too? You'd think there _has_ to be
| a way to do it.
| jeroenhd wrote:
| User certificates still work fine. Apps have to opt into the
| user CA store (many of them don't) but any app deployed by IT
| should be fine. Chrome works, Firefox can be made to work,
| and I believe the Gmail app also works with user CA
| certificates.
| gh02t wrote:
| Thanks for the clarification, I was pretty confused by the
| article on this detail myself. Per app opt seems like a
| reasonable compromise for my use as long as the browser
| recognizes my CA, as that's the one I care about.
| jeroenhd wrote:
| The biggest issue is that the developer needs to opt in,
| the user can't decide "my email client should trust this
| certificate".
| severino wrote:
| I was also confused about that. I don't use an Android phone
| currently, but I remember you could add your own CA
| certificates to an Android phone -without being root, just
| using some option under settings- and at least applications
| like the web browser would trust them. And I'm not talking
| about long ago. So I couldn't understand if the need of
| _rooting_ your device to install custom certificates was for
| something different.
| jeroenhd wrote:
| On Android 7, Google changed the defaults for certificates.
| Previously, apps trusted system certificates and user
| certificates unless they opted out. On Android 7, apps have
| to opt into trusting then user certificate store.
|
| Browsers opt in, or in the case of Firefox, can be configured
| through hidden settings to opt in. Many other apps don't,
| though.
|
| If you're trying to intercept traffic or use apps that should
| opt in but don't, the system store could be altered with root
| access so that these apps still trusted the certificates
| you're trying to inject. However, most apps worth their salt
| implement certificate pinning, so that's hardly reliable
| anymore. It's Arnold workaround that works on some apps but
| not on most.
|
| Furthermore, Google Chrome and derivatives require
| certificates to be logged publicly so malicious CAs can't
| mess with random domains. Your private CA isn't logged in the
| public record, so adding the certificate to the system store
| actually breaks HTTPS for many browsers. You can add the cert
| to both stores to make it work, but it's kind of a hack.
|
| On iOS loading certificates is easier, but you'll still need
| to work around certificate pinning if you want to intercept
| HTTPS traffic.
| severino wrote:
| Thanks for your explanation! What I remember is from an
| Android version more recent than 7, probably 10, but maybe
| the browser was Firefox so in that case there was no need
| to have your device rooted.
| 8organicbits wrote:
| One alternative is to use public CAs on your private networks.
| I've been working on tooling for this at getlocalcert [1]. Side
| stepping the need to add a trust root makes the public on
| private approach a net win for some networks. I honestly wasn't
| expecting Android to block private CAs, but I guess here we
| are.
|
| [1] https://www.getlocalcert.net/
| Hackbraten wrote:
| That looks super convenient! However, some reverse
| engineering tasks would still require root CA certificates,
| for example observing app traffic.
| agwa wrote:
| You can install your own CA certificate in the user certificate
| store, and it will be trusted by Chrome and any other app which
| opts into user-installed CAs, which should include email and
| calendar apps.
|
| What is unlikely to work is installing your own CA and using it
| to intercept traffic between apps and the app-makers' servers.
| That sucks - you should be able to inspect what your own device
| is doing - but your use case of using a private PKI for your
| self-hosted software is definitely supported.
| Brian_K_White wrote:
| You should also have the final say in what is NOT trusted.
| Not merely adding a cert to trust.
| tssva wrote:
| You can disable individual system certificates in the
| "Trusted credentials" settings panel.
| charcircuit wrote:
| >That sucks
|
| It's insecure. If you are a bank app you doesn't want other
| people to be able to steal the users password by installing a
| new certificate.
| Brian_K_White wrote:
| Tough shit. If you are a lot of things you want or don't
| want a lot of things. It doesn't mean they have a right to
| the thing they want or don't want.
| mardifoufs wrote:
| How often does this happen on phones? Why do banks still
| allow desktop usage then?
| charcircuit wrote:
| It doesn't matter how often it happens. It's a
| vulnerability that people will end up being exploited or
| the data will end up being stolen by another hacker.
|
| Not all banks allow desktop usage. Some banks restrict
| certain functionality from the web interface since it is
| less secure.
| feanaro wrote:
| It absolutely matters how often it happens. Otherwise we
| should start imprisoning everyone in the hopes of getting
| that one serial killer by the same principle. Some cures
| are worse than the disease.
| zb3 wrote:
| This is not the same scenario as the user installing a new
| certificate themselves.
| charcircuit wrote:
| Someone's company can install a certificate onto
| employee's work phones.
| keyme wrote:
| People here just love their locked bootloaders for some reason.
| But once you free yourself of this silliness, and root all your
| devices after unboxing, you'll be good for yet a few more years.
|
| Of course it'll only keep being this easy temporarily. Here's a
| scene from 2026 for your imaginative pleasure:
|
| Door: You need to scan your COVID25 vaccine QR code to open this
| door.
|
| QR App: This app will only run on a HW attested device
|
| ------
|
| Shopkeeper: We only accept WhatsApp pay at this store.
|
| Payment App: This app will only run on a HW attested device
|
| ------
|
| Your friend: We can only talk on this one messaging app that
| everybody uses.
|
| Messaging app: This app will only run on a HW attested device.
| Oh, but we promise that this encrypted blob of executable code
| that you can't disable is here just to ensure the _safety_ of
| your E2E encryption.
|
| ------
|
| Your custom ROM rooted Android 18 phone: Running a secure
| messaging app that was banned from the Play Store and has only
| like 2 other active users in the world.
|
| The police: Papers please. _Phone touches the scanner_. _Scanner
| beeps and turns red_.
|
| The law: You have violated the Digital Safety Act. Daily driving
| a non-licensed general purpose computer is illegal as this may
| endanger "our children".
|
| The law: You have violated the Public Health and Safety Act.
| Daily driving a non-licensed general purpose computer is illegal
| as this may be used to circumvent your quarantine and vaccination
| control status checks.
|
| ------
|
| I can go on and on. I think you get the gist of it. Once we have
| HW attestation fully figured out, these laws will come. Cash will
| go away. Your agency will go away. Etc.
|
| ... And the punchline of the ghost story? The guys coding this
| stuff up? They're here with us reading this thread. Commenting
| about the virtues of locked bootloaders for your security.
| hnav wrote:
| Googlers are adding attestation to web standards so you can't
| use escape through the browser. To be fair, Google stands to
| benefit from this and they get paid in Google so the incentives
| line up.
| smoldesu wrote:
| Everyone with two motes of influence over the browser market
| wants to do this: https://httptoolkit.com/blog/apple-private-
| access-tokens-att...
|
| It's bad. It's especially bad on platforms where you don't
| get to choose which browser you run, but we should protest it
| everywhere.
| bitsandboots wrote:
| This is just an effort by Big Outdoors to get us to go outside
| by giving us nothing else to do. /s
| jchw wrote:
| I'm daily driving a Pinephone Pro. Interesting note out there:
| Chase.com tries really, really, really hard to block you from
| using non-standard browsers (like Librewolf) as well as
| phone/tablet browsers (it will try to force you to use the mobile
| application.)
|
| At least until WEI becomes mandatory, this isn't really a serious
| problem, since these braindead measures are all easily bypassed.
| However, I am interested if there is any potential legal avenue
| to pursue given that Chase is a bank. My first guess would be ADA
| compliance, but I'm not sure. At this point, I'm so fed up that I
| am not sure if it is an empty threat anymore to say that I'm
| interested in filing lawsuits over this.
|
| (I realize this is a tangent, but it's relevant because it
| underscores yet another facet of how leaving the oligopoly of
| mobile phone operating systems is damn near impossible. Android
| will just keep getting worse, probably even if the Linux phone
| niche miraculously grows to a couple percentage points; we need
| _something_.)
| CalRobert wrote:
| "At least until WEI becomes mandatory"
|
| Sadly I think Google has killed the open web with this. It was
| getting boring anyway. But it's annoying how much harder it is
| to live without a phone/"approved" browser, etc. now.
| criddell wrote:
| If there's an accessibility feature that you need and can only
| get with an alternative browser, then you should contact Chase.
| It's great if an expert user knows how to fix a problem by
| installing extra software, but it would be even better for
| Chase to make a change to their basic website that would help
| even novice users with similar needs.
| px43 wrote:
| By continuing to be a Chase customer, you are supporting their
| predatory stance, and signaling that it's okay for the rest of
| the industry to adopt the stance as well.
| jchw wrote:
| I may very well leave Chase over this issue, but unless we
| can convince a critical mass of people to care about this
| issue deeply, I think we're screwed. Me leaving Chase will do
| nothing, except perhaps restore a tiny bit of my dignity.
|
| But, I do have a bigger problem: where do I go to signal that
| I care? "Anywhere" is an answer, but is it a good one? Who
| can I trust to _not_ do this?
|
| And in addition, if I'm going to leave over it, I'm going to
| at least make noise first.
| horsawlarway wrote:
| Dark ages are a-coming. Seriously.
|
| We are going to have an age of digital serfdom. You will use a
| device provided to you by some "benevolent" corporation. They
| will own every aspect of that device and you will only be
| allowed to drive it if you give them money (pay your access fee
| today!).
|
| They will lock down most other avenues, general computing will
| be reserved for "corporate" use only, and while there will be a
| "free web", it will be fairly technical and user hostile, and
| the vast majority of marketplaces (ex: anything that touches
| money) will avoid it like the plague.
| jchw wrote:
| None of us individually can fix the problem we're faced with,
| but I'll tell you what we can do: Be the biggest possible
| pains in the ass about it, and that's _exactly_ what I intend
| to do. I 'm planning on digging my heels as deep as they go
| and just causing as much trouble for everyone. Believe me, if
| my browser gets blocked based on user agent, the owners
| _will_ hear about it. I _will_ bypass it. (I _am_ bypassing
| it in many cases.) If you try to push me to a mobile app, I
| 'm either going to find a way to use your website, or I'm
| taking my business elsewhere at basically any cost necessary.
| For me, the end of the open web is scorched earth. I intend
| to gain approximately nothing from this, and I don't care.
| horsawlarway wrote:
| Yeah - No joke, I'm right there with you.
|
| I just don't think it will matter. There is too much money
| on the table, and too much pressure on the "security" front
| to get most of the people implementing this to just...
| stop. They have rational reasons for doing the things
| they're doing, and they're sitting in the "corporate
| developer" spot, which will still get the goodies like a
| real server that can run real code.
|
| I'd like to see some real government regulation... my basic
| stance is - if I own the device, I should get a key to
| _EVERY_ fucking lock it has, including all the digital
| ones. Which seems very sane, and completely mirrors the
| same stance for ownership of things like houses and cars
| (the owner gets all the keys).
|
| But the government (at least in the US) has lodged the
| corporate phallus SO far down its fucking throat it's
| literally choking to death. So I don't expect any miracles.
| cmurf wrote:
| But you don't really own the device. Since day 1 Apple
| has been opposed to this on all their hardware, but most
| especially iOS hardware. You have the right to use it as
| they provide, or destroy it. Ergo you own the physical
| device minus all firmware and software. You have no right
| to inspect, understand or modify the firmware or software
| in any way. By extension, there is no right to repair.
|
| This highly successful paradigm is now replicated by John
| Deere, and Tesla. WiFi radios are being locked down.
|
| I remember folks on HN warning of the slippery slope a
| decade ago, universally shot down. Security!
| horsawlarway wrote:
| Sure, and this is why I utterly refuse to buy Apple
| hardware (note - I'm still forced to use Apple hardware
| by my place of employment... sort of making my point).
|
| It's also why I've chosen to do things like selfhost my
| own services, run my own computing hardware (literally
| sitting in my basement), contribute to and fund open
| source initiatives, and continue arguing that the
| government should regulate this behavior.
|
| Because frankly... I agree with you: it's a highly
| successful paradigm. If left alone and unregulated,
| companies that don't abuse their customers in this manner
| will become less and less prevalent.
|
| I call it "the little green man" paradigm: They have a
| literal enforcer sitting inside your phone who only
| answers to them. They use that little green man to extort
| rent from you for services and goods that shouldn't
| require any sort of ongoing or recurring expense, but
| will... because rents * * cough * * excuse me,
| "subscriptions" are just wonderfully profitable.
|
| I'm just not an optimist on this front.
| 2OEH8eoCRo0 wrote:
| You don't have to gain anything- it's called not
| sacrificing your principles. Something many here don't
| understand. If we don't like something we don't have to put
| up with it but it might take some sacrifice.
| horsawlarway wrote:
| > Something many here don't understand.
|
| This is a complete cop out, and a misunderstanding about
| how this works.
|
| This is a principle that works right up to "Can I feed my
| kids" and then it doesn't work at all.
|
| Principles are flexible. Some are more flexible than
| others. You NEED food in a way that you don't _need_
| general purpose computing. If you are forced to choose, I
| know which one people will pick.
|
| They will just put a finger on the scale to make it more
| and more difficult to choose an open solution. You will
| start losing things like income, job opportunities,
| government access, etc.
|
| They don't have to make you switch... they just have to
| make an environment where you are _less_ fit. Make your
| life harder at every step, limit your opportunities, and
| wait for you to go extinct. And... you will.
| 2OEH8eoCRo0 wrote:
| I'm complaining about the users around here who will not
| sacrifice the smallest convenience for their stated
| principles.
| eternityforest wrote:
| The problem is that too many people hate tech... The people
| who would otherwise want unrestricted general computing now
| want no tech at all, or they only want tech as a platform to
| explore ideas, sort of an external neural enhancement, but
| not as an ubiquitous presence used by everyone for most daily
| tasks.
|
| FOSS is falling farther and farther behind commercial tech,
| and people actively _don 't_ want feature parity with
| commercial apps, they want faithfulness to an interesting
| technical vision, and they want things that stay out of the
| way and are made of modular pieces, rather than things that
| do as much as possible and come with their own opinionated
| workflow you just learn and use.
| wsgeorge wrote:
| Funny how your comment reads like my iPhone user experience
| (minus the "pay your access fee today!")
|
| I personally do not have a problem with these serfdoms, as
| they meet a real, functional need. It does suck that there
| aren't as many easy alternatives for smartphones as there are
| for laptop computing.
| BizarreByte wrote:
| I just don't see how 'general computing' can ever be taken
| away from those determined to have it. Forget the latest,
| fastest CPUs for a moment and focus on what general computing
| really is.
|
| I can build a computer from scratch from existing knowledge I
| have stored in my head. Computing that I'm in control of
| really can't really be taken away from me on a basic level.
|
| I don't disagree though, the web itself is becoming a
| hellscape and I expect it to be completely and totally locked
| down within my lifetime. I don't think the web most people
| know is savable anymore.
| spiralpolitik wrote:
| Watch what happens when the bottom finally drops out of
| Intel and the cloud retreats behind their own custom ARM or
| RISC-V server optimized SoCs. Open hardware sources will
| dry-up.
|
| There are very few OSS hardware vendors that are in a
| position to pick up supporting the whole ecosystem
| enchilada. System76 is the only one that comes to mind.
| They seem to understand to some degree where the puck is
| heading.
|
| While 'general computing' can't be taken away, what an
| individual or small company can support won't be able to
| compete with the locked down systems, especially if the
| upstream efforts are spread across multiple open source
| fronts.
| snvzz wrote:
| >While 'general computing' can't be taken away, what an
| individual or small company can support won't be able to
| compete with the locked down systems, especially if the
| upstream efforts are spread across multiple open source
| fronts.
|
| This is a very pessimistic view.
|
| IBM never designed the PC to be future proof. It just
| happened to pick up.
|
| RISC-V standardization extends to the boot process and
| the platform, facilitating a standard PC that's cleaner,
| simpler and better than the current incidental IBM PC
| derived platform, which has accumulated much baggage
| since 1981.
|
| The platform standard being open and simple minimizes the
| effort the software side (esp. the OS) needs to spend on
| supporting the hardware.
| horsawlarway wrote:
| It's not that you won't be able to have a general purpose
| computer, it's that nothing that touches valuable services
| will be accessible to it.
|
| You can run your toy rpi hobby server, but you won't be
| able to buy goods, check your bank statements, file your
| taxes, buy your insurance, pay your rent, check your email
| or message your mom.
|
| Doing any of those things will require getting permission
| from the gatekeepers of those services, and your device
| won't get it if you have root.
|
| In the _BEST_ case: the government heavily regulates what
| those gatekeepers can do. In the worst... they
| "convenience fee" away absolutely all surplus productivity
| so a very small group of people holding digital keys gets
| to be stunningly rich.
| BizarreByte wrote:
| > it's that nothing that touches valuable services will
| be accessible to it. > Doing any of those things will
| require getting permission from the gatekeepers of those
| services
|
| I don't see how we aren't already at this point.
|
| I can be locked out of my banking tomorrow for any reason
| by the bank or government, banking apps won't run on
| rooted phones or even many browsers, I can be banned from
| email providers and I can't reasonably host my own as big
| providers won't accept messages from my server, etc.
|
| That's not even touching on how companies like CloudFlare
| are effectively already the gatekeepers of traffic to any
| service you would want to use.
|
| From my perspective the future you're scared of is here
| already and only getting worse.
| 2OEH8eoCRo0 wrote:
| Just wait until everyone's favorite benevolent company misses
| earnings for a quarter or two.
| GenericDev wrote:
| I'm so sick of this.
|
| I don't feel like I own my devices anymore.
| jeroenhd wrote:
| Why not buy a phone with known good LineageOS support if you're
| afraid Google may update your phone? You can audit and compile
| the entire OS yourself and disable any CA certificates you may
| dislike.
| exabrial wrote:
| Don't worry, you don't. Just wait until they lobby and make it
| illegal do to do so! This will come under one of the following
| guises:
|
| 1. Save The Children
|
| 2. Save The Planet
|
| 3. Save the Tax revenue
|
| 4. Anti-Terrorism
| [deleted]
| g1a55er wrote:
| [dead]
| dvngnt_ wrote:
| the more they move towards apple levels of control, the less
| reason people have to sick with android.
| shortrounddev2 wrote:
| I use android because I dislike the Apple ecosystem and UI
| design. They could disable all side-loading of apps and I would
| still use Android because I just don't use mobile as my primary
| driver. For me, phones are for texting and browsing Reddit
| while I shit.
| hbn wrote:
| > I just don't use mobile as my primary driver. For me,
| phones are for texting and browsing Reddit while I shit.
|
| That's the reason I use an iPhone. I don't need a bunch of
| customization and homescreen tinkering, I just want a thing
| that gets the job done and is easy to troubleshoot.
| shortrounddev2 wrote:
| I want the same thing, but which also isn't an Apple
| product
| bitsandboots wrote:
| It really makes me think... should we all have bought
| into blackberry/palm/windows' smartphone efforts in the
| 2010s? They seemed inferior at the time but, in
| hindsight, it's hard to imagine anything worse than where
| we are now.
| shortrounddev2 wrote:
| The Nokia Lumia 1310 was the best phone ever made. Best
| UI, best screen and Camera of its generation, and you
| could program apps in C# for UWP so they ran on Desktop
| or Mobile (For that reason, there are still hobbyists who
| sideload new apps on their Lumias since the SDK still
| exists and works on modern windows). Like all things,
| Microsoft made the best version of the product, but not
| the most successful version
| seized wrote:
| But you don't HAVE to do those things on Android.... My
| Pixel is exactly that, gets the job done without problems
| or fuss.
| diogenes4 wrote:
| Hah, I have exactly the opposite reaction as you: I think
| Android is a complete mess in terms of usability.
|
| The big differentiator, though, is your social network.
| Having iMessages and FaceTime is about 95% of the value of
| the phone/tablet for me because my friends heavily, heavily
| use them.
| shortrounddev2 wrote:
| I use Line (kind of like a Japanese/Korean whatsapp) to
| communicate with my wife's family (Wife, sisters in law,
| mother in law), I use Facebook to communicate with my
| parents, and I don't have any friends to communicate with
| on other platforms, so I don't miss iMessage (maybe I don't
| have friends because I don't have iMessage).
|
| Otherwise the apps define most of the UI. Android is
| basically an app launcher to me.
| gambiting wrote:
| I think it's the case of knowing what you know. IOS design
| language depends a lot on being familiar with iOS already -
| I think a lot of Android design is dictated to be
| understandable by people who really haven't used a phone
| before so things are a bit clearer and more obvious. I know
| when I use my wife's iPhone it's so frustrating because it
| feels like you should be able to do action X but there
| isn't any clear way on how to achieve it - I ask my wife
| and she shows me that it's hidden behind some invisible
| menu or gesture and I'm like "how were you supposed to know
| this???" And she just shrugs "it always worked like this".
| Ok, I guess, but that's really poor for discoverability.
| toolz wrote:
| not sure how typical I am, but I don't buy android for really
| any other reason than I can get brand new smartphone that does
| everything I want for under $200 and has multiple sim slots
| (which makes international travel much easier)
|
| At this point apple or anyone else would have to beat the cheap
| android handily for me to consider switching and that seems
| like a tough market to beat. I'm always impressed by how well
| cheap androids work when compared to their 3-4x more expensive
| counterparts.
| jackdh wrote:
| You can pick up second hand ( good condition ) iPhone's for
| not much more. I would also then argue iPhone's last longer
| and tend to get more updates for longer than their android
| counterparts.
|
| They can support multiple ESim's now which I've had fantastic
| experience with when travelling abroad. Apps like Ubigi make
| it super easy to switch to a local sim.
| mrguyorama wrote:
| The problem with used iPhones is that the hardware is still
| powerful enough to run modern iOS, the battery only has
| about a year left to live so unless you budget in a battery
| replacement, you're basically tethered. This may finally be
| clearing up, but Apple's iPhone batteries from the previous
| decade were abysmal and had no headroom for aging. That's
| why they were doing the stupid downclocking of older
| iPhones, because the battery could no longer deliver the
| power to run full bore without browning out.
| simiones wrote:
| Lots of people choose Android entirely unrelated to control -
| especially as this change apparently only affects users of
| rooted Android devices, which are an extremely small minority
| of Android users. Other reasons include price, interop with
| other non-Apple devices, and just a preference for the
| usability of Android vs iOS.
| [deleted]
| bitsandboots wrote:
| Every android release I see things removed, and inconsequential
| things added. It seems like iOS has been doing the opposite, such
| that slowly they may meet in the middle, and then iOS exceed
| android in every way.
|
| Apple folk, can I get an honest opinion here: I've been using
| macOS lately and I hate it because it fails at really basic user
| experience things that've been common on windows/linux for
| decades. Like finder, it's just the worst.
|
| If I were to get an iphone next generation instead of an android,
| would I have the same negative reaction to iOS? Would you say
| that iOS is a more complete, useful UX than macOS, for the
| smartphone use case? I think I want to make the jump, but I also
| don't want to waste my time/money.
| mardifoufs wrote:
| Yes and when the Appstore restriction is removed and
| sideloading apps becomes trivial, I literally can't think of a
| single thing android would have over iOS. It's such a shame
| since android used to be much more than just iOS but with .apk.
| Given_47 wrote:
| I don't use my iPhone for much more than for scrolling hn
| during breakfast, portable audio player, looking random things
| up if I'm on the go, and making calls. It's fine for that. But
| the user is so restricted (u can look into jailbreaking), I try
| to use my phone the bare min and use my desktop for everything.
|
| For context this is also someone in the midst of dumping macOS
| for Linux as well
| atlas_hugged wrote:
| They have a return policy. Give it a shot with a prepaid
| carrier like Mint.
| exabrial wrote:
| We really need a third operating system for phones.
| bitsandboots wrote:
| We had them. Nobody bought them and here's what we got. BB10,
| WebOS, Windows Phone
| exabrial wrote:
| I _really really_ enjoyed WebOS but it gambled way too hard
| on "Web Only" for the time period, and didn't really learn
| the lesson from Apple's attempt at the same thing. I only
| gave my device up after the screen broke.
|
| And damn, that hardware keyboard layout was fire.
| wiseowise wrote:
| Firefox OS.
| Hackbraten wrote:
| There is: https://pureos.net
| maven29 wrote:
| Say hi to ebpf, now shipping with android kernels.
___________________________________________________________________
(page generated 2023-09-05 23:02 UTC)