Android Chrome 99 expands Certificate Transparency, breaking all MitM dev tools
httptoolkit.tech
httptoolkit.tech
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.
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.
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...
[Edit: User introduced VPNs are another issue, but it then falls down on stopping a user from meddling with their phone, which is also tricky in my opinion]
When they have that capability it’s not a big leap to other things.
This kind of stuff was already happening at so many level. Before https everywhere I was seeing a phone carrier auto-proxying requests and injecting additional ads on the way back. I can’t imagine they just gave up on the revenue stream when pages switched to https.
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.
As someone who runs their own cloud top to bottom with custom CAs, adding a trusted root CA is a pain. Removing the ability for me to run ym CA takes away control of my own device from me and puts it in the hand of the big companies.
You should hard reset your phone when crossing boundaries. You would do the same if somone borrwed your clothes.
Would you lend some one your clothes with your passport and wallet in it? Then why is a phone any different.
Like I said, there are a lot of things they could have done better here. But the threat is real and its not some tinfoil conspiracy by "big tech." It is our job as technologists to first and foremost do what we can to protect the 99.999% of users who do not run their own CA.
I don't think it is some big conspiracy, but it isn't a good situation.
Finally, the current implementation is not effective at protecting against country-level MITM. Attempts at country-level MITM have been thwarted by browser updates to blacklist the respective CA certs, the same can be done on Android.
I agree those are legitimate threats that need to be addressed, but there are better ways to do so, which don't come with the convenient side effect of killing privacy research.
Good luck refusing if it is an edict from some governments.
CT's design really doesn't make sense if the goal is to protect against local malware. Why would it need public legers of Merkle trees containing every issued certificate if it was just to protect against local malware?
Anyways, local malware isn't in Chrome's threat model:
https://chromium.googlesource.com/chromium/src/+/master/docs...
Disclosure: Google employee
Regardless of the documentation, Chrome does roll out changes to protect against local threats. I think they just don't want to be on the hook to address every local threat. Happy to give examples in private if you want to email me.
Disclosure: ex-Google employee
>"The installation of an additional root CA cert potentially undermines the security of all your software and communications. When you include a new trusted root certificate on your device, you enable the third-party to gather almost any piece of data transmitted to or from your device."
I understand how they could decrypt any communication between the VPN client and the VPN server but if I was already encrypting my data using a browser that wouldn't give them anything more than encrypted traffic. I do understand the overall threat of these companies installing a Root CA but is that particular passage a little disingenuous or am I missing something much more obvious?
Encrypting against whose keys? The website you are visiting? The malicious VPN company?
The entire point of user-added root CAs is that they can place themselves between you and whoever you're communicating with and intercept/modify it all. And you're unlikely to be warned about it at all.
A VPN provider is in the perfect position to MITM all of your traffic, swapping out any site's public keys with their own in real time. If your VPN app has installed an alternative Root CA on your device, you'll get no warning that this has happened.
https://www.chromium.org/Home/chromium-security/root-ca-poli...
"If you’re an enterprise managing trusted CAs for your organization, including locally installed enterprise CAs, the policies described in this document do not apply to your CA. No changes are currently planned for how enterprise administrators manage those CAs within Chrome. CAs that have been installed by the device owner or administrator into the operating system trust store are expected to continue to work as they do today."
In other words, locally installed certificates are normally treated as trusted by Chrome.
Give everyone root, sure they can mandate some mitm whatever at the border but it won't matter once you disable it with your root...
I think the post you are responding too is far more salient than these bogeymen you are inventing...
Sure, there are going to be issues with some folk installing spyware, but honestly not having root hasn't solved this issue.
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/ECH/whatever 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 anymore.
I think that you are correct.
However, there is also such things as dynamic IP addresses, which might also have to be considered if you want to store DNS data entirely locally.
I once had someone challenge me on HN arguing that the IP address for HN was dynamic, with no proof. However I know it rarely changes because I have the DNS data stored locally and I have not changed it in years. It is baffling to me why some people refuse to accept that most DNS data can be, and in fact is, relatively static. It is too easy to test. Perhaps those who like to use DNS for load balancing do not appreciate the idea of the end user making the choice of which working IP address to use. However, they can, and in my case, they do.
I wish this wasn't the case, because this includes all the things I need to access through the VPN, so several times per week I have to go rerun the "DNS lookup this list of domains and static route the resulting IP addresses through the VPN" script again.
That's half the story. A load balancer (static IP) will often offload the traffic to another IP. Dns is not doing much for you here.
Furthermore, DNS often has a significant lag time between changes - switchovers usually measure in days, relying on dns to cover your routing is usually only pratical with a custom dns resolver anyways.
Even in the case of websites with truly dynamic access like this, then, it's enough to run a targeted query from your local resolver - an argument for local resolvers over your custom-roll-a-script solution...
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.)
That problem would correctly be solved in a different way. "http://example.com/" is different from "https://example.com/" and so would have different cookies, auto-fill, etc. An indicator can be used in the location bar or status bar if needing to indicate the protocol and security clearly. The browser also should not auto-fill anything without the user's permission, regardless of protocol and TLS.
That protection essentially already exists with the secure bit in cookies and the __Secure- prefix.
The problem is that http:// links exist all over the web, and a website owner cannot force all incoming links to say https:// instead. Without HSTS, any time a user clicks one of those links, the user's ISP will be able to see the exact URL the user is visiting, and might even inject ads or other stuff[1] into the page. HSTS solves that.
Disclosure: Google employee, and my license plate is HSTS
>If the user writes "http" then it is http, if the user writes "https" then it is https
Should we also block the website from doing a redirect to https:// ? HSTS is basically just a redirect cache.
OK, but users who do know what it means should be allowed to configure it differently. The computer software should be designed for advanced users, who do know what it means (and includes documentation in case you do not know).
> I want to use https:// if it's available, and http:// otherwise. Should every time I want to click a link, I instead right click to copy the link location, then paste it into the URL bar and modify it to https:// to try that, and then if it fails to load, change it back to http:// ?
No; it should be configurable to do it automatically how you want to do.
> I want it to just work without all that hassle and having to keep a info in my mind of which websites support https:// and which don't.
There are also other ways to do that even without HSTS, though. Still, it should be configurable by the end user.
> Should we also block the website from doing a redirect to https:// ?
No, that it isn't up to the client side to block. (I think that most web sites should not automatically redirect in this way, but that is not related to the client software.)
> HSTS is basically just a redirect cache.
Then it is deficient since it is not the only kind of redirect. Furthermore, it is bad because it does so without the user's specifying if they want this cache or if the user wishes to override it for any reason, making some things difficult to do. It should not try to think they know better than the end user what the end user is wanting to do.
Yeah, I agree. In order to avoid bloat, it might be best to offload this to extensions.
>No; it should be configurable to do it automatically how you want to do.
I agree, but I think complex configuration should be offloaded to extensions. By default it should do what the website owner wants (HSTS).
>Then it is deficient since it is not the only kind of redirect.
Other kinds of redirects aren't relevant for security, so they don't need as the degree of cache guarantees that HSTS provides.
>Furthermore, it is bad because it does so without the user's specifying if they want this cache
Stuff should be secure by default. We don't want security to be opt in.
>or if the user wishes to override it for any reason, making some things difficult to do.
I agree there should be overrides.
>It should not try to think they know better than the end user what the end user is wanting to do.
Sometimes the end user actually doesn't know what the end user is trying to do and gets phished. I agree there should be overrides though, but they need to be carefully designed so that attackers can't abuse them.
While it is a good idea to avoid bloat, there are some problems with this:
- The web browser is too bloated already, and its features are not offloaded to extensions. (If they were (offloaded to extensions which are then included with the browser by default), then it would be easier to customize those features, and the extension mechanism would be sufficient to add new HTML commands, file formats, protocols, character encodings, etc too.)
- WebExtensions is incapable of many things. (I don't know if it can affect the location bar behaviour, but XPCOM is capable and is what I have done on my computer. One thing that WebExtensions definitely does not do is to load native .so files natively. Of course native code should not be available in the public extension catalog, but would be useful for advanced users who can add it by themself.)
> I agree, but I think complex configuration should be offloaded to extensions. By default it should do what the website owner wants (HSTS).
I think it should be unnecessary. If you have a header overriding option, then it makes many other settings unnecessary, and the user can then make settings for cookies, languages, HSTS, referer, JavaScripts and other features (using CSP), user agent override, and many other things, without needing separate settings for those things.
> I agree there should be overrides.
Yes, but unfortunately the HSTS specification, and web browser authors, does not want.
> Sometimes the end user actually doesn't know what the end user is trying to do and gets phished. I agree there should be overrides though, but they need to be carefully designed so that attackers can't abuse them.
I think differently. It might need to be a separate program, which is the "advanced users web browser", you can override and set everything. I don't like this modern software that is not designed for advanced users. Software should be designed for advanced users.
One idea is that a better implementation can be a web browser engine which consists of a lot of independent components (HTTP, HTML, CSS, PNG, JavaScript, WebAssembly, key/mouse events, ARIA, etc; available as separate .so files perhaps (with their own source code repositories)) that can then be tied together by a C code (the main program); a programmer can modify or rewrite some or all parts of this code, to make a customized web browser with your own functions changed.
I think commonly used features should be built in, and rarely used features or features where people can't agree on how the UI should look, should be in extensions. I think HSTS customization would be a rarely used feature, so should be in an extension.
I think I agree that most of what you're saying would be ideal. I'm not sure how much of it is doable though when you consider programmer time constraints.
Unfortunately doing it makes it difficult to work. Also, the extension mechanism is deficient.
If multiple kinds of web browsers are made, so that it is not a monopoly, then they do not all have to be made the same way.
They shouldn't all be Chromium or whatever; they can be something else. If you have separate components, then you can more easily replace them or tie them together differently, without having to use inefficient extensions, modify the source code (which is large and might take a long time and be complicated), waste disk space and memory on unused features, etc.
That is why I think that separating out the components might make it easier for other people to independently build multiple browsers.
That's a bad reason to do things. Users will learn what is made important to them. Red website for http, green website for https. Nice big lettering to translate to the non technical user 'Protected' mode versus 'Unsafe' mode.
Yeah for power users show all the nitty gritties, but this isn't about being technical or not - it's not being communicated properly and instead its just hidden.
When your spouse doesn't communicate well with you, starts having an affair, and then hides it, _thats NOT a good thing_.
All this talk of pasting urls...thats not how users use the web. Nobody is keeping in mind which websites support https or not. They do care what happens when they browse.
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.
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.
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.
From what I understand in the post, desktop Chrome and Android Chrome are the same. If you add the user-added CA to the user store, it doesn't need CT. If you add the user-added CA to the system store, it does need CT. On desktop, everyone adds them to the user store. On Android, most reverse engineers added them to the system store, which causes the problem.
> I don't see the threat model they are addressing.
The idea is that if it's in the system store, Chrome thinks it must be a real CA and thus needs to follow real CA rules, whereas if it's in the user store, it's a weird CA that the user likes and wants to be treated specially, so the CA doesn't need to follow the rules.
To focus more in on threats: a system CA is a big juicy target for hackers or malicious governments, because it can issue a cert that any device will trust, so it needs lots of oversight, like CT. As opposed to a user CA, which is something tiny, that likely only this specific user trusts, so it's not a big target for hackers, and thus doesn't need to follow CT. This whole thing breaks down if the user adds a cert into the system store, because then Chrome thinks it's a big target and needs a lot of oversight, when actually it's a tiny target and doesn't.
Disclosure: Google employee
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.
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.
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.
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.
Yeah, that one I kinda agree with. I don't want most apps to be able to disable that. It's one of the first lines of defense in protecting a device's privacy, and I doubt most people would understand the potential impact if any app could even ask to disable it. That one can be left in the main settings.
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.
That said, TOFU is only less secure in practice, not in theory. The "in practice" is because users do not actually compare the cert with anything. They will always just click "Trust."
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.
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.
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.
Google is one of these manufacturers. I just checked an up-to-date Pixel 6 and it did not have this option.
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™ which is what your users want, is the Web PKI.
So this actually makes sense?
The WiFi alliance should have specified a domain name instead of an SSID, then you could just have checked the certificate for that.
What an OS.
For carriers, it is not necessary at all. LTE networks use different mechanism for communicating assigned IP addresses.
LTE w/ PDN still uses DHCPv6 PD or SLAAC (or both) https://i.imgur.com/2dKAw5W.png
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?
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.
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.
Yeah PD will give you a much an overkill block but there isn't really much of a block shortage. More importantly the alternative is NAT44 on the CLAT so only a single V6 address is required, this is actually what the standard says implementations "SHOULD" do in the single IP scenario as after all 464XLAT doesn't support peer to peer or inbound anyways. And of course people and orgs are free to simply want DHCPv6 on their devices even if it isn't perfect for every scenario.
A "Android doesn't want to support NAT44 for 464XLAT, assign a prefix the the device for the 464xLAT use case" stance I could totally understand. Or even "Carriers are not asking Android to support DHCPv6 deployment methods on LTE, DHCPv6 will only be supported on wireless" is very understandable. The current stance isn't like these though, it's simply "we don't like that type of deployment so we don't allow it". Or maybe I've just missed something big and there is a reason I should have forced a couple customers away from their use cases.
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.
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.
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!
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.
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://bugs.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.
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...
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?
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.
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
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.
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.
The proxy also converts http to https so all requests get encrypted regardless of which HTTP method is specified. "HTTPS everywhere" but not only for accessing www sites with a "modern" web browser but for any program with network access making DNS lookups and 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 setup would suit other computer users but it works for me.
In the past privoxy has been good but it seems quite neglected recently, especially wrt TLS-related functionality.
Be careful what you wish for.
Winning the war requires legislation that demands devices and software be introspectable by all users, not just ones that can set up cheeky mitm proxies.
Why am I suddenly getting the "just go get some legislation" treatment? I could just as well give you a lesson about how trying to prevent corporate MITM middleboxes with technological means is a lost cause and you should just work on getting some legislation to prevent it.
> it would need to be compatible with existing MITM tooling
In my ideal world it wouldn't be, it would be done on the endpoint before/after the traffic is encrypted/decrypted. There would be no need to mitm anything, the OS would happily show you the content and be legally required to provide facilities for the user/software to do so.
Regulating away mitm proxies doesn't make sense because we don't need to do it, you can prevent middleboxes with nothing other than tech by breaking the ability to mitm connections.
You can, because you're talking about middleboxes. But you can't really prevent the owner of the device from MITM-ing traffic, you can just make their life needlessly harder. Or you can attempt to make them not be the owner of the device, so that they are not fully in control, which is unacceptable.
I agree middleboxes shouldn't exist, but the only reason they are able to is because you're not the owner of the device you're communicating from. That's a problem you can solve with legislation.
> In my ideal world it wouldn't be, it would be done on the endpoint before/after the traffic is encrypted/decrypted. There would be no need to mitm anything, the OS would happily show you the content and be legally required to provide facilities for the user/software to do so.
This sounds technically unfeasible. HTTP can be done by any number of userland libraries. How is the OS to ensure that all such libraries are compliant?
On top of that, you're talking about the creation of a new kind of protocol for this kind of thing here. There's an insane amount of tooling currently using HTTP proxies for this which cannot be easily replaced.
Except the "me" in that sentence isn't you, it's whatever apps you have installed.
But what alternative would you propose?
Monitoring is an absolute necessity and positive thing on certain networks.
Good. That's where it belongs.
Think your smart TV or Chromecast. Suddenly, they can do anything they want and you cannot stop them.
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.
[0] https://arstechnica.com/gaming/2021/09/riot-games-anti-cheat...
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.
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.
It can be a desired function sometimes (e.g., a bank that wants to protect its customers) but in most situations it comes back at their face (i.e., bank customer wants to manage his bank account from his work office).
About your conclusion, I fully agree with you. It is not about protecting users but about protecting Google. Let's not ignore the other fact that Chrome started hiding some requests from its Network panel (e.g., CORS) for "our own good", which makes network-layer inspection even more necessary.
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.
It's just harder to do when you don't know what you're doing, which is a good thing in my opinion.
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.
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.
It really is not at this point in time :(
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...
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.
https://github.com/Tampermonkey/tampermonkey/issues/644#issu...
V2 extensions are no longer allowed but there's still no progress or path for Tampermonkey to even experiment with.
Given that, it's quite clear it's a malicious move to take control away from the user.
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
In fact, I'm considering a switch to Apple just to try out a completely deGoogled routine (barring work email).
Truth. However this is a blip on the radar compared to the treacherous monstrosity that is the play integrity api
There are important reasons for performing TLS inspection aside from "developers testing their smartphone app" or "security research".
An employer should want to see the contents of what is traversing the employer's network. The employer owns the network so she gets to decide.
A home computer user should want to see the contents of what is traversing the home computer user's network. The home computer user owns the network so she gets to decide.
Anything, apps from "tech" companies, that interferes with the ability of the network owner to see the contents of that traffic is a threat.
FN1.
https://security.stackexchange.com/questions/107542/is-it-co...
https://fak3r.com/2015/07/22/your-employer-runs-ssl-mitm-att...
https://www.quora.com/Why-are-companies-trying-to-inspect-SS...
https://it.slashdot.org/story/14/03/05/1724237/ask-slashdot-...
https://www.schneier.com/blog/archives/2019/11/the_nsa_warns...
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
With no way to disable this, it seems more about the security of the apps than about the security of the user.
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.
yep, that's what I do. still seems to work here though. I'm scared to reboot
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.