[thaumasiotes]

> The problem with internal CAs is also that it's really hard to add them on some OSes now. Especially on android since version 7 IIRC

That's because the purpose of certificate pinning is to protect software from the user. Letting you supply your own certificates would defeat the purpose of having them.

[Arch-TK]

Certificate pinning and restricting adding custom certificates to your OS except if you're using MDM are two completely unrelated things. Overriding system trust doesn't affect certificate pinning and certificate pinning is no longer recommended anyway.

[freedomben]

They are certainly different things, but they're not unrelated. The inability of the user to change the system trust store is part of why certificate pinning is no longer (broadly) recommended.

[Arch-TK]

Certificate pinning is mainly an obstacle to using an intercepting proxy to inspect and modify the traffic of an application. If you're doing that kind of stuff you already know how to bypass the annoying OS level certificate store restrictions or how to modify an application to disable certificate pinning. The reason certificate pinning is no longer broadly recommended is because of how it makes it more difficult to rotate certificates in the case of necessity, and has nothing to do with the restrictions certain operating systems place on easy installation of your own certificates.

[okanat]

Protect the software from the user? Why are you giving them the software then?

[noirscape]

A lot of mobile software is just a UI around an external web API. The main reason why Android makes it difficult to get the OS to accept an external certificate (you need root for it) is because without it, you can just do a hosts hack through a vpn/dns to redirect it to your own version of that API. Which app manufacturers want to prevent since it's a really easy way to snoop on what endpoints an app is calling and to say, build your own API clone of that app (which is desirable if you're say, selfhosting an open source server clone of said software... but all the official applications are owned by the corporate branch and don't let you self-configure the domain/reduce the experience when you point it to a selfhosted domain).

It's extremely user-hostile since Android has a separate user store for self-signed CAs, but apps are free to ignore the user store and only accept the system store. I think by default only like, Chrome accepts the user store?

[Arch-TK]

Android locking the system certificate store has nothing to do with preventing people from intercepting app traffic for the purpose of inspecting an application and everything to do with preventing people from accidentally installing a malicious certificate which allows part or all their traffic to be MITM-ed.

[thaumasiotes]

Those are literally the same thing.

[Arch-TK]

No, there are legitimate reasons to install a certificate to intercept traffic as an owner of a device. But the same tools can be abused by malware and by malicious actors to intercept traffic. Its the same in a strictly technical sense but not the same in the intent sense. The intent is to prevent malicious abuse of the feature, not justified non-malicious use. It helps make it harder to intercept application traffic but this is not the intent of the restriction, merely an unintended consequence.

[TeMPOraL]

Most software is tools of control and exploitation, and remains in an adversarial relationship with its users. You give software to users to make them make money for you; you protect the software from users so they don't cut you out, or use software to do something you'd rather they don't do.

Software that isn't like that is in a minority, and most of it is only used to build software that is like that.

[cobbal]

It's interesting that cert pinning cuts both ways though. It can also be a tool to give users power against the IT department (typically indistinguishable from malware)

[TeMPOraL]

Cert pinning often annoyingly works against both - software devs are a third party to both the organizational users and their IT dept overlords.

Trusted computing is similar, too. It's a huge win for the user in terms of security, as long as the user owns the master key and can upload their own signatures. If not, then it suddenly becomes a very powerful form of control.

The more fundamental issue is the distinction between "user" and "owner" of a computer - or its component, or a piece of software - as they're often not the same people. Security technologies assert and enforce control of the owner; whether that ends up empowering or abusive depends on who the owners are, and why.

[wkat4242]

> The more fundamental issue is the distinction between "user" and "owner" of a computer - or its component, or a piece of software - as they're often not the same people.

Often? Only really in the case of a corporate computer. But Android locks these things down for everyone. In fact corporate owners can do things normal users can't.

For example I've heard (not confirmed) that with a Knox license you can add root CAs on Samsung. I don't think it's still possible with other MDMs or other vendors.

[TeMPOraL]

> Often? Only really in the case of a corporate computer.

On the contrary, that's the more common case. It's the case with any computer at work (unless you're IT dept), in any work - there's hardly a job now that doesn't have one interacting with computers in some form or fashion, and those computers are very much not employee-owned. Same is the case in school setting, and so on. About the only time you can expect to own a computer is when you bought it yourself, with your own cash. The problem is, even when you do, everything is set up these days to deny you your ownership rights.

[wkat4242]

True. It's almost never to the benefit of the user. The same with "attestation" technologies.

[evandrofisico]

For example, to make it harder to reverse engineer the protocol between the app and the server.

[kbolino]

Isn't certificate pinning on the way out? e.g. https://blog.cloudflare.com/why-certificate-pinning-is-outda...