4 ms·

May I ask a stupid question? Last time I heard about HPKP was as a solution to prevent an attacker from installing a fake root CA certificate in the client syst

by groue 10y ago

May I ask a stupid question? Last time I heard about HPKP was as a solution to prevent an attacker from installing a fake root CA certificate in the client system (a mobile device), so that it could observe the behavior of a mobile app, by posing as its API server (for any purpose of reverse-engineering). Is such an attack possible, and HPKP a reasonable solution to it?

aianus 10y ago
HPKP is ignored by browsers when the certificate chain presented by the website includes a user-installed root CA. This is so enterprises can continue to MITM their employees' connections on their work machines.
ivanr 10y ago
No, it is not; locally-installed CAs (roots) bypass HPKP.
hannob 10y ago
This happens, see Superfish and friends. HPKP does not protect against this, it's an entirely different set of problem. HPKP's only purpose is to protect against malicious or compromised CAs.
- groue 10y ago
  Yes, like a rogue one installed through any jailbreaking technique, isn't it?
vbezhenar 10y ago
Locally trusted CA certificates circumvent HPKP protection, because many organisations use TLS MITM attack to spy on their staff and browsers must support it in order to work properly in those environments. But it makes sense for browser. If you are making your own application, you can implement it in any way. Simplest way would be to embed public key in the application and check it without HPKP. Though, probably, if your app is popular, you'll face that in some networks your connections are MITMed and you (or user) can't do anything about it, so it's choice about dropping security or not to work at all.
- groue 10y ago
  > Simplest way would be to embed public key in the application Yes, but one eventually faces the need to update the certificate on the server, and still support installed applications (which fails when apps have an obsolete certificate pinned). Hence the need for smooth certificate updates, and the good smell of HPKP. But it addresses another need, hence my confusion.
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.

by groue 10y ago

aianus 10y ago

HPKP is ignored by browsers when the certificate chain presented by the website includes a user-installed root CA. This is so enterprises can continue to MITM their employees' connections on their work machines.

ivanr 10y ago

No, it is not; locally-installed CAs (roots) bypass HPKP.

hannob 10y ago

This happens, see Superfish and friends. HPKP does not protect against this, it's an entirely different set of problem. HPKP's only purpose is to protect against malicious or compromised CAs.

groue 10y ago
Yes, like a rogue one installed through any jailbreaking technique, isn't it?

vbezhenar 10y ago

Locally trusted CA certificates circumvent HPKP protection, because many organisations use TLS MITM attack to spy on their staff and browsers must support it in order to work properly in those environments. But it makes sense for browser. If you are making your own application, you can implement it in any way. Simplest way would be to embed public key in the application and check it without HPKP. Though, probably, if your app is popular, you'll face that in some networks your connections are MITMed and you (or user) can't do anything about it, so it's choice about dropping security or not to work at all.

groue 10y ago
> Simplest way would be to embed public key in the application Yes, but one eventually faces the need to update the certificate on the server, and still support installed applications (which fails when apps have an obsolete certificate pinned). Hence the need for smooth certificate updates, and the good smell of HPKP. But it addresses another need, hence my confusion.

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.