3 ms·

It's strange to see Android take this extremely anti-local-CA stance, while Chrome on the desktop does the exact opposite, even bypassing key pinning if a local

by 0x0 10y ago

It's strange to see Android take this extremely anti-local-CA stance, while Chrome on the desktop does the exact opposite, even bypassing key pinning if a local CA is in the chain. https://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters- https://www.chromium.org/Home/chromium-security/security-faq... Especially so since Android since 5.x already shows a huge obnoxious "Your network may be monitored" if you have installed a local CA. It's a shame you can't configure certain domains to ONLY trust a specific LOCAL CA system-wide. It would completely eliminate the security problem that is untrustworthy or hacked global CAs, for example for your own/enterprise mail server.

pfg 10y ago
The way I understand it, this only affects apps, not Chrome for Android. Chrome on desktop follows the HPKP RFC on this matter[1]. Failing pins that chain up to local CAs would break many deployments. On mobile, apps that implement certificate pinning are usually already broken if a MitM proxy is used, so it's a different context and this move improves the situation for apps that haven't moved to cert pinning yet (it's not a full replacement as it only helps with the "malicious local CA" problem). The implications of an attacker being able to import a CA certificate are different on mobile as well, IMO. On desktop, this usually implies administrative access, in which case anything Chrome could do would be pointless, as the attacker could also just replace/modify binaries, install a keylogger, etc. Android has a more fine-grained permission system, and an attacker who tricks a user into installing a CA certificate would not necessarily be able to do these things, so this would definitely make things harder for them. [1]: https://tools.ietf.org/html/rfc7469#section-2.6 https://tools.ietf.org/html/rfc7469#section-2.6

by 0x0 10y ago

pfg 10y ago

The way I understand it, this only affects apps, not Chrome for Android. Chrome on desktop follows the HPKP RFC on this matter[1]. Failing pins that chain up to local CAs would break many deployments. On mobile, apps that implement certificate pinning are usually already broken if a MitM proxy is used, so it's a different context and this move improves the situation for apps that haven't moved to cert pinning yet (it's not a full replacement as it only helps with the "malicious local CA" problem). The implications of an attacker being able to import a CA certificate are different on mobile as well, IMO. On desktop, this usually implies administrative access, in which case anything Chrome could do would be pointless, as the attacker could also just replace/modify binaries, install a keylogger, etc. Android has a more fine-grained permission system, and an attacker who tricks a user into installing a CA certificate would not necessarily be able to do these things, so this would definitely make things harder for them. [1]: https://tools.ietf.org/html/rfc7469#section-2.6 https://tools.ietf.org/html/rfc7469#section-2.6