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 <i>particularly trustworthy</i>. 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.<p>We (mitmproxy) have repeatedly tried to get an answer to this from the Android folks (e.g. here: <a href="https://github.com/mitmproxy/mitmproxy/issues/2054#issuecomment-282585162" rel="nofollow">https://github.com/mitmproxy/mitmproxy/issues/2054#issuecomm...</a>). It very much feels like they just want to kill uncomfortable privacy research.
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.<p>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.<p>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.<p>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.<p>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!<p>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.
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.<p>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.
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).
"Browsers receiving this traffic enforce that all certificates they receive come with a matching SCT, signed by a log provider they trust."<p>Interesting the word is "they" and not "you". Assuming "they" means the "tech" companies that provide these browsers and "you" means the computer owner.<p>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.<p>Can the computer owner remove a "trusted" log provider.<p>Can the computer owner add their own log provider.<p>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.
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."
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.<p>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.<p>In which case I guess the next step would be... Add a fake CT log in addition to the fake root CA?<p>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.
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.<p>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.
An issue not mentioned in this is that at the office it is routine to MITM TLS connections, what some call "TLS inspection".[FN1]<p>There are important reasons for performing TLS inspection aside from "developers testing their smartphone app" or "security research".<p>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.<p>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.<p>Anything, apps from "tech" companies, that interferes with the ability of the network owner to see the contents of that traffic is a threat.<p>FN1.<p><a href="https://security.stackexchange.com/questions/107542/is-it-common-practice-for-companies-to-mitm-https-traffic" rel="nofollow">https://security.stackexchange.com/questions/107542/is-it-co...</a><p><a href="https://fak3r.com/2015/07/22/your-employer-runs-ssl-mitm-attacks-on-you/" rel="nofollow">https://fak3r.com/2015/07/22/your-employer-runs-ssl-mitm-att...</a><p><a href="https://www.quora.com/Why-are-companies-trying-to-inspect-SSL-TLS-traffic-of-their-employees" rel="nofollow">https://www.quora.com/Why-are-companies-trying-to-inspect-SS...</a><p><a href="https://it.slashdot.org/story/14/03/05/1724237/ask-slashdot-does-your-employer-perform-https-mitm-attacks-on-employees" rel="nofollow">https://it.slashdot.org/story/14/03/05/1724237/ask-slashdot-...</a><p><a href="https://www.schneier.com/blog/archives/2019/11/the_nsa_warns_o.html" rel="nofollow">https://www.schneier.com/blog/archives/2019/11/the_nsa_warns...</a><p><a href="https://attack.mitre.org/mitigations/M1020/" rel="nofollow">https://attack.mitre.org/mitigations/M1020/</a>
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.
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<p>There is also env SSLKEYLOGFILE, that you can use on connection with Wireshark, but I didn't tested that yet with chrome<p>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
The flag he mentions seems like a reasonable way to support the debugging use case. It's more to setup, but people doing this should already be using automation to install the cert, etc.
<i>"HTTP Toolkit gives you one-click HTTP(S) interception, inspection & mocking for any Android app."</i><p>There's kind of a vested interest here.<p>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.
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.