[HN Gopher] Android Chrome 99 expands Certificate Transparency, ...
___________________________________________________________________
Android Chrome 99 expands Certificate Transparency, breaking all
MitM dev tools
Author : pimterry
Score : 203 points
Date : 2022-05-11 16:13 UTC (6 hours ago)
(HTM) web link (httptoolkit.tech)
(TXT) w3m dump (httptoolkit.tech)
| 1vuio0pswjnm7 wrote:
| "Browsers receiving this traffic enforce that all certificates
| they receive come with a matching SCT, signed by a log provider
| they trust."
|
| Interesting the word is "they" and not "you". Assuming "they"
| means the "tech" companies that provide these browsers and "you"
| means the computer owner.
|
| Computer owners are usually given the run-time option to remove
| "trusted" root certificates that are pre-installed with browsers
| like Chrome. That is, remove them from the current list of
| trusted root certificates, not remove them from the source code.
| In a more perfect world, more computer owners could compile their
| own browsers,[FN1] thereby giving them the opportunity (freedom
| of choice) to remove untrusted certificates from the source code,
| as well as to add their own. Not to mention make other useful
| changes suitable to their own needs.
|
| Can the computer owner remove a "trusted" log provider.
|
| Can the computer owner add their own log provider.
|
| FN1. I prefer to rely on a localhost proxy to perform TLS instead
| of the browser. One benefit is that I can read, edit and compile
| the proxy source code myself, quickly and easily. Unlike the
| graphical browser from the online ad services "tech" company, the
| author(s) of the proxy are not compromised by a pecuniary
| interest in selling and delivering programmatic advertising
| services, and the ability to use an in-house browser to support
| that pernicious endeavour. In using a proxy, I am not having to
| fight against the interests of the paternalistic browser vendor
| in order to protect my own.
| 1vuio0pswjnm7 wrote:
| I am not using a localhost proxy for "security". I do not use
| the proxy when performing any sort of commercial transaction or
| other important transaction using a graphical web browser
| issued by a "tech" company. That usage comprises a very small
| portion of overall computer use. I normally use TCP clients for
| making HTTP requests and a text-only browser for reading HTML.
| y4mi wrote:
| > _I prefer to rely on a proxy to perform TLS instead of the
| browser._
|
| That's one step forward and about 30 steps backwards if you're
| actually doing that for security. Proxies silently accept
| broken TLS configuration all the time and serve then to you as
| https secured. You're unlikely to encounter invalid https
| configurations nowadays, so you likely won't ever notice, but
| it's definitely less secure to break the TLS connection in the
| proxy
| zzo38computer wrote:
| > Proxies silently accept broken TLS configuration all the
| time
|
| I don't want the browser to enforce TLS configuration; the
| proxy could be configurable to set it how I want it to accept
| or not accept broken TLS configurations.
| zzo38computer wrote:
| > I prefer to rely on a localhost proxy to perform TLS instead
| of the browser.
|
| I also would want to do this (it would be more efficient than
| needing to decrypt and encrypt it twice), but unfortunately the
| options for the proxy configuration does not seem to allow
| that.
| 1vuio0pswjnm7 wrote:
| I do not use the browser's proxy configuration. I use
| localhost DNS to direct HTTP traffic to the proxy.
| zzo38computer wrote:
| That won't work for HTTPS unless you decrypt and encrypt
| it, which is less efficient, or not use HTTPS URLs, which
| will break many other things (and also has some
| inefficiencies when using with stuff that does use HTTPS),
| etc.
| 1vuio0pswjnm7 wrote:
| Efficiency is not the goal in my case. The proxy
| configuration does decrypt then re-encrypt, but that is
| exactly what I want because I want to be able to examine
| and manipulate requests.
|
| The configuration also converts http to https so all
| requests get encrypted regardless of which HTTP method is
| specified. "HTTPS everywhere" but not only for a
| difficult-to-control browser but for any client trying to
| make HTTP requests.
|
| I generally do not use a "modern" browser. More often I
| use TCP clients that have no support for TLS. It is
| unlikely this configuration would suit other computer
| users but it works for me.
| technofiend wrote:
| If you've ever tried to use 802.1x / EAP on Android then you've
| already had a taste of this issue. Android makes importing and
| trusting a new root certificate authority very difficult. At
| least in my experience the device constantly pops up warnings
| about the root ca, despite using the appropriate import options.
| And if you're paranoid enough to use wifi client authentication,
| then you probably don't want anyone else to issue certs for your
| devices.
|
| On one hand it's commendable that Google makes it hard on
| malicious actors, but on the other there are legitimate use cases
| for importing your own root CAs and using something stronger than
| WEP is just one of them.
| ollien wrote:
| > If you've ever tried to use 802.1x / EAP on Android then
| you've already had a taste of this issue. Android makes
| importing and trusting a new root certificate authority very
| difficult.
|
| Good lord don't get me started. In worked at a NOC in college
| part-time and a significant part of my job was helping users
| onboard devices to the network and determining where there were
| gaps in our onboarding process. After a random security update,
| all Pixel phones just ... stopped being able to connect to our
| network and we eventually determined that you needed to go
| through a new, non-obvious path to import a CA for our EAP-TLS
| certificates. I'm not remembering the details but unless you
| connected _exactly_ right on the first try, it would delete the
| CA certificate and you'd have to start over. There's a lot of
| other details here but it ended up taking us almost a month to
| find the exact path to get things up and running.
|
| We also paid a vendor (SecureW2) for an app to enroll devices
| on the network, but Google removed the ability for users to
| edit configurations generated by apps. Our network required
| disabling MAC randomization at the time (which Google provides
| no API for apps to disable). Before the change, users would
| enroll, and then disable MAC randomization to complete setup.
| However, because users were no longer allowed to edit these
| configurations after the app had gotten everything else
| configured, they were left dead in the water.
|
| On the flip-side: Apple makes this very easy and provides a
| "profile" mechanism that users can download and get everything
| set up in a few clicks.
| hackmiester wrote:
| This is seriously such a joke because for years Android had a
| "don't check certificate" option for 802.1X. It was unique
| among the most popular client OSes in allowing this extremely
| unsafe configuration, which is way worse than "trust on first
| use" (the least secure option in iOS). And now suddenly a total
| 180, they are extremely anal about certificates to the point
| that 802.1X is very hard to use. Thanks a lot gang.
| hedora wrote:
| "Trust on first use" is not always less secure than using a
| CA.
|
| With trust on first use, if you validate that the certificate
| matches the one you expect, then you're good as long as the
| server and your device are not compromised.
|
| If you go the standard route and use a certificate authority,
| then a compromise (due to law enforcement or not) of the
| certificate authority will cause your device to silently
| trust a third party MITM certificate.
|
| A lot of hidden implicit trafeoffs like this become apparent
| once you realize that your personal threat model is only
| loosely aligned with Google's.
| kevincox wrote:
| It's worse. A compromise of _any_ certificate authority
| will do this.
| tinus_hn wrote:
| 802.1x certificate checking is a big mess because it is
| totally unclear what the certificate should certify.
|
| The WiFi alliance should have specified a domain name instead
| of an SSID, then you could just have checked the certificate
| for that.
| jeroenhd wrote:
| My university used to recommend explicitly selecting "do not
| validate" for the longest time, even though validation
| through the system store (or a certificate of your choice)
| has existed for years.
|
| For what it's worth, if you're using a valid TLS certificate
| for your 802.1x setup then you don't need to load any
| certificates anymore (at least not since Android 10 or 11).
| Users may need to enter a domain to validate, though; I don't
| know the specifics of these protocols.
| hackmiester wrote:
| Not every modern Android device offers the "use system CA
| store" option. And chromebooks don't. We just gave up and
| kept loading the certificate.
|
| You also have to understand that "valid" doesn't really
| mean anything. When android supports the system CA store,
| they're the first and only OS to do it this way. It doesn't
| make a ton of sense to try to do this because there is no
| domain to validate. Unless it's preconfigured, in which
| case you may as well have loaded a root CA.
|
| That's what we're doing now (preconfiguring the root CA).
| Then the server sends a valid cert and trust chain, just
| not within the typical global PKI infrastructure.
| jeroenhd wrote:
| From what I'm reading about this online the domain
| validation thing is part of the WPA3 spec, though it's
| clearly more visible on Android. Perhaps they removed
| their WPA2 code path and stuck to WPA3 exclusively but I
| think this is a way forward rather than a problem; it's
| too easy to accidentally import a root certificate
| authority into the trust store when you're trying to get
| the WiFi going and that's a security risk. The stupid
| warnings should still disappear when you import the CA as
| an EAP certificate of course. I'm pretty sure most modern
| operating systems will (some day soon) connect to
| enterprise networks configured the way Android likes it
| without ever needing to install a certificate, which is
| an obvious benefit to me. The domain itself is either the
| entered domain or the domain of the identity you entered,
| I believe this is also based on some part of WPA3.
|
| Validating the common name through the system CA store is
| also an option on Linux, though you have to select the
| system certificate store manually instead of specifying a
| PEM file that you can never move again.
|
| I don't know about Chromebooks but I think the system CA
| validation setting is standard in Android since either
| Android 10 or Android 11. Android 11 added validation of
| the certificate (presumably through OCSP stapling?) but
| that's disabled by default. If you're not on Android 10+
| I'm not sure if I'd call that a "modern" Android version
| anymore with how quickly manufacturers drop support for
| older Android versions. I'm pretty sure Google already
| dropped security support for Android 9 anyway.
|
| It's possible that some manufacturers broke the setting,
| but if they did they should've added their own
| replacement. You can't blame Google for broken Android
| forks imo.
| Avamander wrote:
| It's unfortunate that the SSID can't be automatically used
| as the domain on the TLS certificate.
| hackmiester wrote:
| Unfortunately this wouldn't help us because we are an
| eduroam identity provider. The SSID is always eduroam but
| the cert presented is different, based on your username,
| because your login is handled by your home institution
| (the IdP responsible for your identity).
| Avamander wrote:
| Yeah, eduroam is a bit more special in that aspect. I can
| imagine it working in quite a few other cases though.
| tialaramex wrote:
| But I believe Android _does_ care about the domain an
| Eduroam user said their user is in. So, if your user says
| I 'm example@mit.edu I think it will expect the
| certificate from the 802.1X server (at MIT) to have a
| certificate for mit.edu, which is what will happen in
| Eduroam.
|
| The certificates used are PKIX certificates, they say
| they're for TLS Server Authentication (which they
| technically are) and the subjects are DNS server names
| (these are, after all, servers on the Internet) and so
| realistically the only PKI exercising any oversight over
| such certificates so that it could Just Work(tm) which is
| what your users want, is the Web PKI.
|
| So this actually makes sense?
| baisq wrote:
| If you need something stronger than WEP you have WPA2 and WPA3.
| technofiend wrote:
| Yeah, you're right. I should have included those, but I'm
| really talking about per-client certificate authentication vs
| a shared secret.
| zamadatix wrote:
| Android's networking team has historically been very
| opinionated and unwilling to support use cases they don't
| consider to be the right way. It and ChromeOS are still the
| only things actively refusing DHCPv6 support for example.
| Avamander wrote:
| Unlike with a lot of what they do, that resistance I
| appreciate. I don't think it's the right way either. I've
| seen firsthand how it's a crutch that lulls some network
| admins into thinking they can just think about v6 as it were
| v4.
| zamadatix wrote:
| I've maintained and deployed dozens of IPv6 networks but
| I'm still not quite sure I follow what you mean. The
| Android teams reasoning was they didn't want networks to be
| able to disallow multiple addresses (particularly carriers,
| not Wi-Fi) but that doesn't really have anything to do with
| treating it like v4 being wrong.
| vetinari wrote:
| Exactly; DHCPv6 would allow to force the device to use
| just a single IP address. In IPv6, you need extra IP
| addresses for tethering; XLAT464 needs entire /96 prefix.
| Allowing DHCPv6 would allow network admins cripple
| functionality like this. It's not like IP addresses even
| in the smallest subnet (/64) are a scarce resource.
|
| For carriers, it is not necessary at all. LTE networks
| use different mechanism for communicating assigned IP
| addresses.
| zamadatix wrote:
| DHCPv6 forces no such thing. 464XLAT can still be done
| via PD though it's really again a carrier thing,
| enterprises will know if they need 464XLAT the device
| doesn't need to force that it would be possible. Same
| story with tethering.
|
| LTE w/ PDN still uses DHCPv6 PD or SLAAC (or both)
| https://i.imgur.com/2dKAw5W.png
| vetinari wrote:
| > DHCPv6 forces no such thing it just allows for it.
|
| I wrote "would allow to force", not that it forces.
|
| > LTE w/ PDN still uses DHCPv6 PD or SLAAC (or both).
|
| Unless you are turning Android device into router, you
| won't need PD support there. What else you need prefix
| delegation for?
| zamadatix wrote:
| > I wrote "would allow to force", not that it forces.
|
| Ah sorry, must have misread my bad. All the same I'm not
| seeing how this plays into why it should be forced, the
| phone is just half the story (the CLAT) and if the
| enterprise wanted to implement 464XLAT they can PD and
| run a NAT64 gateway. If they don't then it's not going to
| work just because the device has enough addresses to be a
| CLAT as there is no NAT64 gateway. Or if they just want
| their devices to dual stack or single stack v6 instead
| why does Android get to decide they need to support
| something they aren't using?
|
| > Unless you are turning Android device into router, you
| won't need PD support there. What else you need prefix
| delegation for?
|
| The prefix for 464XLAT or to allow tethering. DHCPv6-PD
| is how you do this when you're not using SLAAC.
| vetinari wrote:
| > All the same I'm not seeing how this plays into why it
| should be forced, the phone is just half the story (the
| CLAT) and if the enterprise wanted to implement NAT64 and
| 464XLAT they can PD. If they don't then it's not going to
| work just because the device has enough addresses to be a
| CLAT.
|
| You are right. I've used that as an example of why a
| device would want more IP addresses than one. One of
| aspects of treating IPv6-as-IPv4 is the assumption, that
| one IP is enough. I get it, it simplifies logging/reverse
| resolution for example, but one IP might be not enough
| and the example, while not be the best, illustrates the
| point.
|
| > The prefix for 464XLAT or to allow tethering. DHCPv6-PD
| is how you do this when you're not using SLAAC.
|
| There is a difference in scope between PD and SLAAC:
|
| With PD you usually hand out /64 (or bigger) carved out
| of whatever larger subnet you have. So if your upstream
| gets you /48 or /56, this is the mechanism to hand out
| smaller subnets to routers downstream.
|
| SLAAC support allows any device in the subnet to claim
| any address inside the announced prefix it wants, unless
| it is already taken and other device objects. There is no
| limit on how many addresses it can claim, but claiming
| /64 or more would take a while :). Claiming a few is
| enough for tethering to work.
|
| SLAAC is what you get wit RA by default; only those that
| want to force DHCPv6 on their network disable it (yes, I
| tried that once when playing with it. That playing was
| great way to understand why it was a bad idea).
|
| With DHCPv6, even if it is supported in the network,
| doesn't mean you also get PD. It remains completely
| optional. This is a problem with many CPEs (i.e. with a
| class of devices it was designed for!), that are supposed
| to support PD, but the support is either buggy or non-
| existent, thus their users never have more than /64.
| megous wrote:
| All this achieves is that for people who want to subnet /64
| it is not possible on Android without manual setting of the
| address. (and only on android) Yeah and android doesn't
| support manual setting of the IPv6 address in the UI, lol.
|
| What an OS.
| guerby wrote:
| I've always wondered why OSes don't have a specific CA store
| just for 802.1x.
| jeroenhd wrote:
| The constant popups have been removed almost eight years ago,
| right now you get a little (i) in the notification shade that
| says "this network may be monitored". This is the same warning
| that shows when you enable a VPN.
|
| The warning is wrong when it comes to EAP certificates, of
| course, but far better than the constant unnecessary popups
| warning you that you did in fact load a CA cert.
| technofiend wrote:
| Yeah anything that requires acking or creates distrust is a
| no go. I really want to transparently move all devices that
| support it to certificate-based authentication without
| training my wife to ignore or ack warnings. My fantasy is
| that IOT devices add support for it too, but that's just
| crazy talk.
| vetinari wrote:
| > My fantasy is that IOT devices add support for it too,
| but that's just crazy talk.
|
| Maybe not. Recently I played with some relays that support
| MQTT-over-TLS (Shelly 2nd-gen ones). What I liked was, that
| they came with empty CA store, it was up to the user to
| provide all the certs.
| new_user_final wrote:
| This and side-loaded accessibility threads are making me rethink
| how stupid people are. Please read and try to understand before
| typing something on your keyboard that will make you look like a
| stupid.
| holoduke wrote:
| How long before Google only accepts Google signed certificates.
| Everything must and shall be placed within the Google ecosystem.
| Not good.
| woodruffw wrote:
| CT is a PKI ecosystem thing, not a Google thing. Google hosts
| one of the CT logs for HTTPS certificates, but so do other
| major companies: Cloudflare and DigiCert come to mind. Let's
| Encrypt even has one.
| asdf1asdf wrote:
| mhils wrote:
| Enforcing CT is good, but that doesn't excuse the treatment of
| user-added CAs. On all platforms but Android, user-added CAs are
| considered _particularly trustworthy_. For example, Chrome
| Desktop, Firefox, and IE did not enforce HPKP if they encountered
| a cert from a user-added CA. Why does Android do the opposite? I
| don 't see the threat model they are addressing.
|
| We (mitmproxy) have repeatedly tried to get an answer to this
| from the Android folks (e.g. here:
| https://github.com/mitmproxy/mitmproxy/issues/2054#issuecomm...).
| It very much feels like they just want to kill uncomfortable
| privacy research.
| midasuni wrote:
| I want to add a user CA but only for a certain sites. If I'm
| developing on blah.com, I'm happy to add a root certificate,
| but I want to choose what sites (blah.com, blah.de, etc) I
| trust that very to accept, I don't want it doing bank.com
| because I don't trust my own CA management to be infallible.
|
| Name constraints are poorly supported, and even then that again
| relies on me creating the root cert correctly. Browsers seem to
| give me the user the choice of either accepting the cert fully
| or not accepting it, not giving me the control. Why is that.
| smw wrote:
| Yes! Thank you! So many use cases!
| no_time wrote:
| >For example, Chrome Desktop, Firefox, and IE did not enforce
| HPKP if they encountered a cert from a user-added CA.
|
| They have no teeth on these platforms (as of now). Contrary to
| this, Android has been engineered from the ground up to make
| it's inner workings as opaque and unflexible as possible.
| [deleted]
| donmcronald wrote:
| > I don't see the threat model they are addressing.
|
| The threat model they're addressing is the one where users have
| a small semblance of control over their devices and networks.
| I've been saying for years that HTTPS everywhere, DoH, eSNI (or
| it's successor), etc. are part of a long term plan for big tech
| to have absolute control over what users are allowed and not
| allowed to do with their own devices.
|
| You can't see the threat model because, to them, you're the
| threat. From that GitHub issue:
|
| > It does not prevent nor attempt to prevent you from doing
| those kinds of things.
|
| The thing missing there is the _for now_ qualifier. Once they
| know it won 't impact anyone with the power to cause problems
| for Google, they'll remove the config flags and lock us all
| out. The same strategy has been used over and over and over in
| the last 10-15 years.
| zzo38computer wrote:
| > The threat model they're addressing is the one where users
| have a small semblance of control over their devices and
| networks. I've been saying for years that HTTPS everywhere,
| DoH, eSNI (or it's successor), etc. are part of a long term
| plan for big tech to have absolute control over what users
| are allowed and not allowed to do with their own devices.
|
| I had thought so too, and also "secure contexts" (apparently
| there is supposed to be a way to configure this, but it does
| not seem to be the case) and HSTS, too. I think that HSTS is
| very bad. (HTTPS is not bad, but all of these things that are
| forcing them is a bad idea.)
| mike_d wrote:
| As a point of clarification, lest anyone think you are
| actually being serious...
|
| The threat being addressed here is the proliferation of VPNs
| that also install a local trusted root[1], rogue roots being
| installed at border crossings[2], and entire countries
| mandating a MitM root to egress traffic[3].
|
| I do believe they could have done a lot more to improve the
| developer experience, but this does address a legitimate
| security concern for millions of users.
|
| 1. https://www.techradar.com/news/new-research-reveals-
| surfshar...
|
| 2. https://www.vice.com/en/article/neayxd/anti-virus-
| companies-...
|
| 3. https://www.eff.org/deeplinks/2022/03/you-should-not-
| trust-r...
| nine_k wrote:
| These are legitimate concerns, but this is like beheading
| to treat a headache. Technically it works.
|
| I'd suggest to add a notification dialog when a root cert
| is added, and a good, clear UI to manage the certs: when
| added, by what app, disable, remove, etc.
| 1vuio0pswjnm7 wrote:
| People should have the right to choose their own "threat
| model". Google has a threat model. A computer user may have a
| threat model. It is absurd to assume they will always be the
| same.
|
| Google wants to choose the threat model for everyone. There
| is no opt-in or opt-out. One size does not fit all.
|
| Would enjoy more details on how eSNI will be used to exert
| "absolute control". SNI is certainly being used for
| censorship, but would like to know how eSNI can be used in
| similarly malicious ways.
|
| Using DoH run by a third party is optional, as is using
| traditional DNS from a third party. One can still utilise
| these protocols with localhost servers. Computer owners have
| ample storage space today for storing DNS data. I use locally
| stored DNS data. I put the domain to IP address information
| in map files and load them into the memory of a localhost
| proxy.
|
| Public scans from Rapid7 used to be a good public source of
| bulk DNS data in addition to public zone file access through
| ICANN, e.g., czds.icann.org. (A variety of third party DoH
| servers can be use to retrieve bulk DNS data as well.) Alas,
| Rapid7 have recently decided not to share the DNS data they
| collect with the public.
| heavyset_go wrote:
| You're right on the money, and they don't want people reversing
| APIs, either.
| aliswe wrote:
| who doesn't want you reversing their apis, Google? Oh ..
| matt_heimer wrote:
| > For example, Chrome Desktop, Firefox, and IE did not enforce
| HPKP if they encountered a cert from a user-added CA. Why does
| Android do the opposite?
|
| Your examples are all browsers. I understood that Chrome on
| Android will continue to support using a user-added CA added to
| the user store. Android and desktops behave exactly the same
| for web browsers.
|
| Non-browser apps are where the differences exist. On Android
| you must opt-in each app to trust the user store. I'd imagine
| that the next step is automating
| https://github.com/shroudedcode/apk-mitm to bulk replace all
| installed apps with modified apks.
| superjan wrote:
| At least one country that I heard of (Kazachstan) requires
| everyone to install a cert issued by the gouvernement that
| enables them to do this kind of MITM spying on users. That
| could be the argument against allowing user-installed certs.
| bityard wrote:
| So all this is going to do is break the Internet for a whole
| country. Or at least those that use Chrome and Android.
| gbear605 wrote:
| If Android + Chrome is the majority of computer users in
| the country (which it probably is), this might force the
| hand of the government
| xg15 wrote:
| I was kind of believing that most apps would use certificate
| pinning anyway, so I was kinda surprised manipulating the system
| store is actually workable.
|
| Though if modifying the system store is indeed officially
| "unsupported" my guess is it's only a matter of time before CT is
| enforced by the standard Android TLS API and will apply to apps
| as well.
|
| In which case I guess the next step would be... Add a fake CT log
| in addition to the fake root CA?
|
| But anyway, stuff like this confirms my impression that Android
| sides with app developers more than it sides with users when it
| comes to analysing traffic of your own devices.
| Szpadel wrote:
| that's super anoying, as of some time you do not see cors
| requests in dev tools and basically only way to debug those
| issues was to use mitmproxy, and that's now also unnecessary
| complicated
|
| There is also env SSLKEYLOGFILE, that you can use on connection
| with Wireshark, but I didn't tested that yet with chrome
|
| I understand why it's nice from security point of view, but
| adding option to disable those in chrome://flags would be much
| better way
| xg15 wrote:
| > _I understand why it 's nice from security point of view_
|
| With no way to disable this, it seems more about the security
| of the apps than about the security of the user.
| Anunayj wrote:
| Can I simply not choose the CT log I want to use and host my own
| CT log with my certs in there? If I can't doesn't this mean this
| effectively makes it so my cert has to be in Google's CT logs to
| be valid.
| rektide wrote:
| Google keeps seeming like an advanced persistent threat to an
| understandable world. More and more effort keeps getting poured
| into insuring software takes precedence over humanity, that we
| get no say.
|
| The recent banning of sideloaded accessibility apps is another
| blood curddling cry against agency, another slamming shut of the
| door. This totalization of security concerns is such a horrifying
| behavior to have emerged in the past half decade, especially from
| a company so strongly linked to the web and which used to have
| such clear positive values.
| hypertele-Xii wrote:
| On the other hand, if Google vanished today, the only effect
| it'd have on my life is that I'd watch something other than
| YouTube.
| vmception wrote:
| Lucky you
|
| So no email you have from an employer, school, sideproject,
| personal is gmail based? No shared document you are storing
| or access is google docs based? At least everyone making
| calendar invites will quickly move to something else
|
| I'm just really surprised you've managed to do this and are
| content
| unethical_ban wrote:
| In my personal life, YouTube is the only thing that seems
| irreplaceable. My contacts are in Google as well, but i
| have non Google for all backups and email and search.
|
| In fact, I'm considering a switch to Apple just to try out
| a completely deGoogled routine (barring work email).
| hypertele-Xii wrote:
| I actually de-Googled myself very recently. Got my own
| domain, own email, and use SyncThing between devices.
| Melatonic wrote:
| The only effect it would have is that tons and tons of
| people would suddenly be asking you for help on how to
| live without their Google handholding overlords :-D
| sieabahlpark wrote:
| Well it'd be gone anyway, I'd just use one of my other
| emails.
| jeroenhd wrote:
| The "ban" on externally installed accessibility apps is nothing
| more than two extra button presses to enable APIs that are used
| by real-world malware to steal money. Alternative app stores
| like F-Droid are exempt from the change, assuming they use the
| correct API, and apps you manually installed can still be given
| the necessary permissions.
|
| It's just harder to do when you don't know what you're doing,
| which is a good thing in my opinion.
| rektide wrote:
| That is less bad than I thought.
|
| Manifest v3 & it's forbidding of dynamic code is another
| major treason, in my view, an uncompromising & cruel stance
| to force upon the web. I'm less knowledgable here, but I also
| feel like there's a bit of a hostile relationship with works
| like Magisk on Android, which have long had an uneasy
| relationship, albeit the recent v24 & it's new Zygisk zygote
| injection shows a lot of health & excitement right now. The
| ever encroaching desire to drive top-down control is highly
| visible in SafetyNet, which make it clear the device in your
| hand serves corporations, not you.
| SquareWheel wrote:
| If by Manifest v3 you're referring to
| declarativeNetRequest, then that's supported dynamic rules
| since 2019[1][2].
|
| If you mean disallowing importing remote code, that's to
| prevent malware from hiding in Chrome extensions until
| after being published.
|
| [1] https://developer.chrome.com/docs/extensions/reference/
| decla...
|
| [2] https://blog.chromium.org/2019/06/web-request-and-
| declarativ...
| feanaro wrote:
| declarativeNetRequest still doesn't have capabilities
| sufficient to reimplement uBlock Origin functionality.
| Besides that, it puts the power to decide _which_
| blocking capabilities are even possible strictly in
| Google 's hands.
|
| Given that, it's quite clear it's a malicious move to
| take control away from the user.
| rektide wrote:
| It's not just disallowing imported code, it's disallowing
| all dynamic code. This prohibits, for example,
| Greasemonkey/VioletMonkey/Tampermonkey, or any kind of
| extension that has dynamic behaviors.
|
| It's a prime example of draconian security absolutism,
| and it's vile & detestable & anti-human. Enforcing this
| not just on their store, but on the web & extensions in
| general, is an outrage.
| SquareWheel wrote:
| That seems a liiittle hyperbolic. In any case, power user
| tools like Tampermonkey will seemingly be supported.
| Whether that be through special exceptions or new APIs
| remains unclear. Personally I'd like to see integration
| with Local Overrides.
|
| https://github.com/Tampermonkey/tampermonkey/issues/644#i
| ssu...
| rektide wrote:
| Preventing any kind of dynamic agency from growing on the
| web is one of the most severe threats to user-agency I
| can imagine. It's a direct strike at one of the most core
| distinctions that makes the web different from everything
| else. I really believe strongly that the web will advance
| once we start making more adaptive scripts/extensions,
| scripts that can gain & accrue capabilities, and this
| directly prevents advance.
|
| V2 extensions are no longer allowed but there's still no
| progress or path for Tampermonkey to even experiment
| with.
| jeroenhd wrote:
| I agree with you on Manifest V3, the restrictions are
| somewhat understandable if Google didn't stand to gain so
| much from blocking the behaviour they now restrict.
|
| The Magisk project is kind of a weird one, I 100% expected
| Google to neuter that when the dev behind it got hired but
| it's clear that that's not happening.
|
| SafetyNet is a requirement for almost every media company
| out there. Android would die a quick death if Netflix,
| Disney+, and friends would suddenly stop working because
| Google turned good and disabled SafetyNet. There are some
| enterprise advantages to SafetyNet as well, sometimes you
| want to be sure that some internal applications work on
| phones with internal security intact only.
|
| As always, if you don't like the product, vote with your
| wallet, or in this case your data. Don't use Chrome/ium,
| don't sign into your Google account, download from F-Droid
| and Aurora exclusively and root your device if you wish.
| Firefox is still a decent mobile browser, despite Mozilla's
| efforts to change that.
|
| /e/ is an excellent replacement for almost the entire
| Android ecosystem and I think if that became popular among
| non-techies, Google might start to listen. It might also
| not and Android might be doomed, but it's worth a try.
| pmlnr wrote:
| > Firefox is still a decent mobile browser
|
| It really is not at this point in time :(
| josephcsible wrote:
| If it were just two extra button presses then it would be
| fine. The problem is that if you try to use a sideloaded
| accessibility app without pressing them, the error Google
| gives you tells you that it's completely impossible, and
| doesn't mention the button presses.
| Melatonic wrote:
| Yea I see this as a good thing assuming it is not a stepping
| stone to banning sideloading in general. Which I do not think
| they are going to do.
| no_time wrote:
| >Google keeps seeming like an advanced persistent threat to an
| understandable world. More and more effort keeps getting poured
| into insuring software takes precedence over humanity, that we
| get no say.
|
| Truth. However this is a blip on the radar compared to the
| treacherous monstrosity that is the play integrity api
|
| https://developer.android.com/google/play/integrity
| oefrha wrote:
| I always find it highly ironic that I can trivially MitM my non-
| jailbroken iPhone to inspect app traffic (unless the app uses
| cert pinning), but MitM'ing on a non-jailbroken Android phone is
| a huge pain in the ass, basically impossible without patching
| binaries (please correct me if I'm wrong).
| jeroenhd wrote:
| Loading certificates into the phone is as easy as opening the
| files. The problem here is that Android apps have to opt in to
| loading user-imported certificates.
|
| Chrome and many other browsers will load these certificates
| just fine if you install them the official way. Apps that
| specify they trust the user store will also load them without
| any issues.
|
| The method that's now broken fails because the author is using
| a workaround: with root permissions, the system store can be
| altered, which apps do trust by default. Chrome, however, is
| following best practices and enforces that certificates are
| logged in the certificate transparency log. This isn't done for
| user-imported certificates for obvious reasons, but it's
| applied to system certificates to prevent rogue CAs from faking
| certificates without exposing themselves to the world.
|
| This means the workaround no longer works, or at least not as
| easily. There are still workarounds to fix the workaround, like
| the flags the author suggests here. It was never a supported
| way of doing things and unsupported workarounds are bound to
| break at some point.
|
| I don't know how iOS deals with certificates, I suspect it's
| something sensible when the normal API is used (opt-out of user
| certificates, that is). However, apps like social media and
| messengers will often include certificate pinning that is
| impossible to get around without jailbreaks + modifying runtime
| code through tools like Frida. They include the hash of their
| (intermediary) certificates in the application itself and
| validate that the chain is signed by a valid certificate with
| that specific hash. That way, a malicious certificate authority
| can give out a "valid" certificate that's useless for MitM-ing
| your app's users!
| oefrha wrote:
| > The problem here is that Android apps have to opt in to
| loading user-imported certificates.
|
| Yes, but since Android N introduced this change, I haven't
| met a single non-browser app that opted in to trusting the
| user store, or offered an option to do that. Maybe some
| enterprise apps do that? So it's practically broken for any
| non-browser app; as for browsers I'll just use a desktop
| one...
| feanaro wrote:
| Frankly, it doesn't matter _why_ exactly they 've broken it.
| What matters is that it _is_ broken, with no easy way to
| intercept traffic for all apps.
|
| This is an extremely user hostile position from Android and
| Google which is clearly meant to remove oversight over what
| apps send from the hands of the computer owner. I have no
| doubt they'll continue this cat-and-mouse game of trying to
| make it impossible to see the traffic generated by your own
| device.
|
| Now _this_ is something the EU should work on changing
| instead of trying to dismantle E2E encryption.
| zozbot234 wrote:
| This thread is simply about a user-visible warning screen
| in Chrome. It has nothing to do with apps, etc. And the
| warning looks like it's skippable, since it has an
| "Advanced..." option. Not sure how this is supposed to
| impact dev workflows or be user-hostile in any way.
| feanaro wrote:
| It does have to do with the overall topic of traffic
| inspectability.
|
| As explained above, a relatively recent change in Android
| makes applications not trust user store certificates by
| default, except if an application explicitly opt into
| that. ~None of them do, except Chrome.
|
| The solution to that problem was to install the
| certificate into the system store. But now Chrome
| considers all system store certificates to be public ones
| and requires CT for them.
|
| So now there's no way to install a certificate to be able
| to inspect traffic from both Chrome and other
| applications at the same time. (If a certificate is in
| both the system store and in the user store, the system
| store version takes precedence, so Chrome would still
| require CT.)
|
| There's a Chromium bug the author of the article filed to
| document this regression and you can already see a
| Chromium dev argue that "reverse engineering" (i.e. the
| ability to inspect the traffic your own device produces)
| is "understandably" not an addressed scenario: https://bu
| gs.chromium.org/p/chromium/issues/detail?id=132430...
|
| To be clear, this particular change _isn 't_ the end of
| the world, but none of them are since they're just using
| the slow frog-boiling method. Each change makes it a
| little bit harder until eventually it won't be possible
| at all.
| thrdbndndn wrote:
| Ah, thanks for the detailed explanation. Have been wondering
| this for a while.
|
| So if I read it correctly the major difference between the
| two platform is the opt-in/out part.
|
| On iOS I can sniffer some random small apps trivially, since
| most of them don't enable pinning; on the other hand for
| android it's default on ( so I have to manually patch the
| apks everytime.
|
| IIRC "have to opt in to loading user-imported certificates"
| wasn't the case a few generations of Android ago, correct?
| jeroenhd wrote:
| Correct, this changed in Android 7.
| codys wrote:
| what tools/methods exist for MitM-ing iphone traffic in this
| case?
| oefrha wrote:
| Any tool? Install a profile, enable your cert, set a proxy,
| off you go. Charles, mitmproxy, Fiddler, whatever you prefer.
| Melatonic wrote:
| Don't tons of apps now use cert pinning though?
| bspammer wrote:
| On the other hand if the app does use cert pinning, it's much
| easier on Android because we have
| https://github.com/shroudedcode/apk-mitm
| xg15 wrote:
| If you're already patching the APK, couldn't you also patch
| it to trust the user store, even if the app doesn't use cert
| pinning?
| oefrha wrote:
| That's true.
| lesgobrandon wrote:
| NovemberWhiskey wrote:
| Isn't there an enterprise policy for disabling CT for certain CAs
| in Chrome?
| Melatonic wrote:
| I believe there is for desktop but I am not sure on mobile. and
| I am not entirely sure if (without the browser enrolled) it
| would even be possible for the end user to control this.
| Animats wrote:
| _" HTTP Toolkit gives you one-click HTTP(S) interception,
| inspection & mocking for any Android app."_
|
| There's kind of a vested interest here.
|
| It would probably be sufficient to allow cert bypass in a desktop
| Android phone emulator, such as Android Studio. That's intended
| for debug and test. Nobody uses that for non-debug use by
| mistake.
| jeroenhd wrote:
| Note that this only counts for certificates in the system store.
| As far as I know, certificates stores in the user store (the one
| you use when you import a certificate through the UI) will
| override this requirement and work just fine.
|
| The underlying problem is that apps stopped trusting user
| certificates by default in Android 7 so security researchers have
| had to root their devices and store certs in the system store.
|
| Theoretically this should work if you can manage to get the
| certificate in both the system and the user store, though I don't
| think you can do that.
|
| I'm thinking something like this: you add the root certificate to
| your system store so most applications will trust it; then you
| create an intermediate certificate authority for your MitM-ing
| (which you should probably do anyway if you're doing this long
| term) and import that certificate into the user store.
|
| Hopefully, that way Chrome will see the user store intermediate
| certificate and validate it using the non-CT algorithm. I haven't
| tried it, though!
|
| Note that for MitM-ing Firefox, you need to access the secret dev
| settings (go to about, hit the Firefox logo seven times to enable
| them) and enable loading user store certificates.
| Melatonic wrote:
| This is the real answer. While I of course support hardening
| security I have to think that Google has other motivations by
| introducing these restrictions on the system cert store. There
| are legitimate use cases where you want want to MITM yourself
| (or your employer). This combined with cert pinning combined
| with use of encrypted DNS (which is definitely not a bad thing
| in it of itself) means that Google is going to keep having
| access to useful tracking data.
| justsomehnguy wrote:
| > The underlying problem is that apps stopped trusting user
| certificates by default in Android 7
|
| The other casualty were the people who use their own CAs. It
| took me some time to grok what the problem with some apps
| (which didn't want to connect) wasn't in my server
| configuration, but the certs they served.
|
| TLS-ALPN somewhat alleviates this problem, but still requires
| to have some real presence on the net.
| bitwize wrote:
| But how will zScaler provide extra security for your corporate
| apps on Android now?
| verifex wrote:
| Jailbroken androids for the enterprise! What could possibly go
| wrong?
| georgiecasey wrote:
| so this breaks charles proxy HTTPS sniffing as well? I haven't
| encountered the problem yet even though my Android Chrome is
| version 101
| [deleted]
| matt_heimer wrote:
| It doesn't break Charles Proxy unless you installed your CA
| cert in a method that is typically used by httptoolkit
| (installing in the system store).
|
| What is broken is installing a custom CA into the system store
| on a rooted phone and making it work with all apps (apks) and
| Chrome.
|
| If you install the custom CA into the user store it'll still
| work with Chrome.
|
| If you want to use Charles to inspect the HTTPS traffic of an
| app you are developing then you continue to follow the
| instructions from
| https://www.charlesproxy.com/documentation/using-charles/ssl...
| to configure your test build to use the user store CA certs.
|
| If you want to use Charles to inspect apps from other
| developers then you need to rebuild them to trust the user
| store just like you would if you were developing the app
| yourself. Use https://github.com/shroudedcode/apk-mitm to
| automate that process.
|
| httptoolkit uses the method they do because it was the easiest
| way to get setup to inspect everything. Its tedious to get
| every app setup to trust the user store.
| georgiecasey wrote:
| > What is broken is installing a custom CA into the system
| store on a rooted phone and making it work with all apps
| (apks) and Chrome.
|
| yep, that's what I do. still seems to work here though. I'm
| scared to reboot
| Spivak wrote:
| Ya know what, good. It sucks that dev tools caught in the
| crossfire here but anything to put another nail in the broken
| corporate mitm "security" appliances is a huge win. Along with
| encrypted DNS we might actually reach nirvana of "either give me
| a clean connection to the public internet or don't but no stupid
| half broken middle."
| unethical_ban wrote:
| As a network security person, if you can't MitM, then
| monitoring and filtering will simply move to the endpoint.
|
| Monitoring is an absolute necessity and positive thing on
| certain networks.
| Spivak wrote:
| You're describing the world everyone wants. I would much
| rather OS's move to a system with a filtering API so I can
| get real errors like "connection not allowed by local
| security policy" instead of pretending like it works and then
| dropping packets or getting garbage responses from the
| appliance pretending to be my server.
| dane-pgp wrote:
| Of course what we'll actually get is networks which
| require[0] your OS to attest that you are running in Secure
| Boot mode, so the network can ensure you are running an
| "approved" OS that prevents you from running VPNs or Tor or
| bittorrent or E2EE messengers...
|
| [0] https://arstechnica.com/gaming/2021/09/riot-games-anti-
| cheat...
| unethical_ban wrote:
| Hey, I hear you. That just means I'll have to get good at a
| different UI!
| xg15 wrote:
| Ok, but filter on what criteria? If the connection is
| encrypted, how do you know what you should filter for?
| unethical_ban wrote:
| the idea is that device traffic would be inspected by the
| OS via some subsystem that encrypts/decrypts application
| traffic. I'm talking out of my butt here, I am not an OS
| person or a dev.
|
| I imagine instead of the web browser encrypting traffic
| before sending it on the wire, it would send it in the
| clear to a process on the OS ("Endec"? I'm trying to
| think of some word like codec or modem for
| encrypt/decrypt).
|
| This process would be the hub for all endpoint encrypt-
| decrypt operations, and the place where all apps would
| trust to do the work. That way, inspection tools desired
| by the user (or in corp land, the admin) could hook in
| and do filtering.
|
| Applications that don't want this, such as say, Signal or
| other hyper-privacy tools, could choose their own trust
| store and bypass it, if permitted by the OS admin.
| Otherwise, corps could block raw access to the NIC.
| nybble41 wrote:
| > then monitoring and filtering will simply move to the
| endpoint
|
| Good. That's where it belongs.
| vetinari wrote:
| Except for endpoints where the user/owner has zero control.
|
| Think your smart TV or Chromecast. Suddenly, they can do
| anything they want and you cannot stop them.
| nybble41 wrote:
| Devices you can't control are also a problem, but the
| endpoints are still the right places to implement
| filtering. You can't guarantee access to the data anyway,
| as they can always encrypt the content independently of
| TLS. Though they're more likely to pin their own
| certificates so they can't be MitM'd and simply refuse to
| operate in a network environment hostile to end-to-end
| encryption.
|
| It's best to just wall untrusted devices off from the
| rest of the network so they can access the Internet as
| required to do their job but not interact with any of
| your other devices. Or alternatively, replace them with
| open-source devices you do control.
| feanaro wrote:
| Do you know what other thing you've just put into a nailed
| coffin? The ability to inspect traffic your own device is
| making. So now Google and other nasty corporations get to
| decide what they send back to their servers without a
| possibility of you ever finding out.
|
| Be careful what you wish for.
| Avamander wrote:
| We might even be able to use SCTP or TCP Fast Open in the real
| world once those boxes start becoming obsolete.
| xg15 wrote:
| "either give me a clean connection to the public internet or
| don't but no stupid half broken middle."
|
| Except the "me" in that sentence isn't you, it's whatever apps
| you have installed.
|
| But what alternative would you propose?
___________________________________________________________________
(page generated 2022-05-11 23:00 UTC)