8 ms·

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 trustwor

by mhils 4y 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#issuecomment-282585162 https://github.com/mitmproxy/mitmproxy/issues/2054#issuecomm...). It very much feels like they just want to kill uncomfortable privacy research.

midasuni 4y 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 4y ago
  Yes! Thank you! So many use cases!
heavyset_go 4y ago
You're right on the money, and they don't want people reversing APIs, either.
- aliswe 4y ago
  who doesn't want you reversing their apis, Google? Oh ..
no_time 4y 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.
deleted 4y ago
[deleted]
donmcronald 4y 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_d 4y 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-surfshark-turbovpn-vyprvpn-are-installing-risky-root-certificates https://www.techradar.com/news/new-research-reveals-surfshar... 2. https://www.vice.com/en/article/neayxd/anti-virus-companies-now-flag-malware-china-installs-on-tourists-phones-xinjiang https://www.vice.com/en/article/neayxd/anti-virus-companies-... 3. https://www.eff.org/deeplinks/2022/03/you-should-not-trust-russias-new-trusted-root-ca https://www.eff.org/deeplinks/2022/03/you-should-not-trust-r...
  - nine_k 4y ago
    These are legitimate concerns, but this is like beheading to treat a headache. Technically it works. I'd suggest to add a notification dialog when a root cert is added, and a good, clear UI to manage the certs: when added, by what app, disable, remove, etc.
    - deleted 4y ago
superjan 4y 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 4y 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.
  - gbear605 4y ago
    If Android + Chrome is the majority of computer users in the country (which it probably is), this might force the hand of the government
    - chii 4y ago
      i doubt that a technological feature can be used to force the hand of a gov't.
      - na85 4y ago
        That quote about the Australian politician who didn't understand that Australian law can't trump the natural laws of mathematics comes to mind.
        brokenmachine 4y ago
        He was Prime Minister, which says a lot.
- 312c 4y ago
  All three times (2015, 2019, 2020) the Kazakh government tried this the cert was blocked in major browsers.
matt_heimer 4y 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 https://github.com/shroudedcode/apk-mitm to bulk replace all installed apps with modified apks.
- thrdbndndn 4y 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.
Thorrez 4y 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

by mhils 4y ago

midasuni 4y 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 4y ago
Yes! Thank you! So many use cases!

heavyset_go 4y ago

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

aliswe 4y ago
who doesn't want you reversing their apis, Google? Oh ..

no_time 4y 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.

deleted 4y ago

[deleted]

donmcronald 4y 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_d 4y 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-surfshark-turbovpn-vyprvpn-are-installing-risky-root-certificates https://www.techradar.com/news/new-research-reveals-surfshar... 2. https://www.vice.com/en/article/neayxd/anti-virus-companies-now-flag-malware-china-installs-on-tourists-phones-xinjiang https://www.vice.com/en/article/neayxd/anti-virus-companies-... 3. https://www.eff.org/deeplinks/2022/03/you-should-not-trust-russias-new-trusted-root-ca https://www.eff.org/deeplinks/2022/03/you-should-not-trust-r...
- nine_k 4y ago
  These are legitimate concerns, but this is like beheading to treat a headache. Technically it works. I'd suggest to add a notification dialog when a root cert is added, and a good, clear UI to manage the certs: when added, by what app, disable, remove, etc.
  - deleted 4y ago

superjan 4y 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 4y 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.
- gbear605 4y ago
  If Android + Chrome is the majority of computer users in the country (which it probably is), this might force the hand of the government
  - chii 4y ago
    i doubt that a technological feature can be used to force the hand of a gov't.
    - na85 4y ago
      That quote about the Australian politician who didn't understand that Australian law can't trump the natural laws of mathematics comes to mind.
      - brokenmachine 4y ago
        He was Prime Minister, which says a lot.
312c 4y ago
All three times (2015, 2019, 2020) the Kazakh government tried this the cert was blocked in major browsers.

matt_heimer 4y 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 https://github.com/shroudedcode/apk-mitm to bulk replace all installed apps with modified apks.

thrdbndndn 4y 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.

Thorrez 4y 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