Android Chrome 99 expands Certificate Transparency, breaking all MitM dev tools

https://httptoolkit.tech/blog/chrome-android-certificate-transparency/

by pimterry • 4 years ago

288 183 4 years ago

rektide4• 4 years ago

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-Xii2• 4 years ago

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• 4 years ago

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

jeroenhd8• 4 years ago

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.

josephcsible2• 4 years ago

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.

rektide4• 4 years ago

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.

Melatonic5• 4 years ago

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_time2• 4 years ago

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

georgiecasey2• 4 years ago

so this breaks charles proxy HTTPS sniffing as well? I haven't encountered the problem yet even though my Android Chrome is version 101

matt_heimer2• 4 years ago

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.

georgiecasey2• 4 years ago

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

holoduke• 4 years ago

How long before Google only accepts Google signed certificates. Everything must and shall be placed within the Google ecosystem. Not good.

woodruffw• 4 years ago

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.

oefrha4• 4 years ago

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

codys• 4 years ago

what tools/methods exist for MitM-ing iphone traffic in this case?

oefrha4• 4 years ago

Any tool? Install a profile, enable your cert, set a proxy, off you go. Charles, mitmproxy, Fiddler, whatever you prefer.

bspammer• 4 years ago

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

oefrha4• 4 years ago

That’s true.

xg155• 4 years ago

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?

jeroenhd8• 4 years ago

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!

oefrha4• 4 years ago

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

thrdbndndn2• 4 years ago

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?

feanaro6• 4 years ago

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.

Melatonic5• 4 years ago

Don't tons of apps now use cert pinning though?

jeroenhd8• 4 years ago

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.

justsomehnguy• 4 years ago

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.

Melatonic5• 4 years ago

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.

spacexsucks2• 4 years ago

Agreed. This is just another prevention measure to line their pockets

asddubs• 4 years ago

wasn't chrome going to add it's own certificate store? whatever happened to that?

Spivak4• 4 years ago

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_ban4• 4 years ago

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.

Spivak4• 4 years ago

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.

nybble412• 4 years ago

then monitoring and filtering will simply move to the endpoint

Good. That's where it belongs.

Avamander4• 4 years ago

We might even be able to use SCTP or TCP Fast Open in the real world once those boxes start becoming obsolete.

feanaro6• 4 years ago

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.

Spivak4• 4 years ago

But this was already possible, hitching your “I have control over my own device” wagon to “My device allows me to x, y, or z” that are only possible due to history, backwards compatibility, or because not enough people actually do it to be a problem is a battle already lost.

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.

xg155• 4 years ago

"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?

technofiend3• 4 years ago

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.

hackmiester5• 4 years ago

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.

jeroenhd8• 4 years ago

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.

hedora• 4 years ago

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

tinus_hn• 4 years ago

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.

jeroenhd8• 4 years ago

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.

technofiend3• 4 years ago

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.

baisq• 4 years ago

If you need something stronger than WEP you have WPA2 and WPA3.

technofiend3• 4 years ago

Yeah, you're right. I should have included those, but I'm really talking about per-client certificate authentication vs a shared secret.

zamadatix5• 4 years ago

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.

Avamander4• 4 years ago

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.

ollien3• 4 years ago

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.

shakna• 4 years ago

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.

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.

guerby• 4 years ago

I've always wondered why OSes don't have a specific CA store just for 802.1x.

ollien3• 4 years ago

Android kind of does. You can mark a certificate for "VPN and Apps" or for "Wifi". I can't remember if you can do it with CAs, but you can definitely do it with the dependent certs.

Szpadel• 4 years ago

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

xg155• 4 years ago

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.

bitwize• 4 years ago

But how will zScaler provide extra security for your corporate apps on Android now?

verifex• 4 years ago

Jailbroken androids for the enterprise! What could possibly go wrong?

NovemberWhiskey• 4 years ago

Isn't there an enterprise policy for disabling CT for certain CAs in Chrome?

Melatonic5• 4 years ago

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.

new_user_final• 4 years ago

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.

xg155• 4 years ago

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.

nokya• 4 years ago

Certificate pinning is a big problem for corporate environments: large companies install CA certificates in their endpoints to allow centralized traffic inspection. Apps that enforce certificate pining cannot operate properly in these networks.

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.

mhils2• 4 years ago

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• 4 years ago

I want to add a user ÇA 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• 4 years ago

Yes! Thank you! So many use cases!

heavyset_go• 4 years ago

You're right on the money, and they don't want people reversing APIs, either.

aliswe• 4 years ago

who doesn't want you reversing their apis, Google? Oh ..

no_time2• 4 years ago

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.

donmcronald• 4 years ago

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.

mike_d3• 4 years ago

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

zzo38computer11• 4 years ago

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

1vuio0pswjnm710• 4 years ago

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. The interests of Google may conflict with the interests of the computer owner.

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.

superjan• 4 years ago

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• 4 years ago

So all this is going to do is break the Internet for a whole country. Or at least those that use Chrome and Android.

312c• 4 years ago

All three times (2015, 2019, 2020) the Kazakh government tried this the cert was blocked in major browsers.

matt_heimer2• 4 years ago

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.

thrdbndndn2• 4 years ago

Is this tool still working? I tried multiple small apks and they all errored out. Looking at the issues, there are quite a lot similar reports.

Thorrez7• 4 years ago

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.

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

1vuio0pswjnm710• 4 years ago

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

y4mi• 4 years ago

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

zzo38computer11• 4 years ago

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.

1vuio0pswjnm710• 4 years ago

Would be interested to see a list of those "about 30" steps. Surely, the number is neither made-up nor arbitrary.

1vuio0pswjnm710• 4 years ago

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.

zzo38computer11• 4 years ago

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.

1vuio0pswjnm710• 4 years ago

I do not use the browser's proxy configuration. I use localhost DNS to direct HTTP traffic to the proxy. Alternatively one could use firewall rules.

Animats• 4 years ago

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

Anunayj• 4 years ago

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.

lokar• 4 years ago

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.

1vuio0pswjnm710• 4 years ago

An issue not mentioned in this is that at the office it is routine to MITM TLS connections, what some call "TLS inspection".[FN1]

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

https://attack.mitre.org/mitigations/M1020/

josephcsible2• 4 years ago

Are you okay if your ISP starts MITM'ing all of your TLS traffic, since they own the network you're connecting to?

1vuio0pswjnm710• 4 years ago

Who owns the data.

Android Chrome 99 expands Certificate Transparency, breaking all MitM dev tools

Related Stories