4 ms·
No, HPKP is not intended as a mechanism to prevent that. In fact, all user agents I'm aware of do not check pins if the certificate chain leads to a custom CA c
by pfg 10y ago
No, HPKP is not intended as a mechanism to prevent that. In fact, all user agents I'm aware of do not check pins if the certificate chain leads to a custom CA certificate (one that has been installed manually, as opposed to the default root certificates the user agent ships with). (I believe this is a MAY in the RFC, but all major browsers have implemented it that way).
Mobile apps typically have other key pinning mechanisms that are preloaded (i.e. baked into the binary), but that's typically easy to bypass if you're the owner of a device; it's not really effective as a mechanism against reverse engineering.
- groue 10y ago> Mobile apps typically have other key pinning mechanisms that are preloaded (i.e. baked into the binary), but that's typically easy to bypass if you're the owner of a device; it's not really effective as a mechanism against reverse engineering. Your comment makes me realize that HPKP can bootstrap itself, and is unlike regular pinning (with certificate bundled in the binary, as you say). So do you agree that a powerful enough owner of the device should be considered able to setup a server which poses as the regular server the app talks to, and sniff any request the app sends to its server? (edited for spelling)
- pfg 10y ago> So do you agree that a powerful enough owner of the device should be considered able to setup a server which poses as the regular server the app talks to, and sniff any request the app sends to its server? I think any attempt to prevent that is doomed to fail, similarly to how DRM has had absolutely no effect on the availability of pirated content.