4 ms·

Absolutely, I agree with everything you said. Pinning is not an effective anti-reverse-engineer technique. It's just annoying obfuscation to anybody who knows

Absolutely, I agree with everything you said. Pinning is not an effective anti-reverse-engineer technique. It's just annoying obfuscation to anybody who knows what they're doing.

toast0 3y ago
Pinning isn't really for anti-revere-engineering. It does discourage some reverse engineers, which is a bonus. But it's main purpose is to protect data integrity between the client and the server --- there's plenty of cases of CAs in system root stores that issued certs that could be used to intercept and manipulate traffic. There's also plenty of cases where something installed on the user's device adds itself to the system root store and intercepts traffic with the intent of passing it through but does not do so correctly and causes hard to diagnose errors. A pinned cert makes it easy to detect these MITMs and refuse to work if they're in place. A dedicated reverse engineer is "just" going to patch out the pin, and go on with their day, no big deal. But ISP MITM or corporate MITM or on device MITM is going to be stopped, and that's worthwhile.
- jcalvinowens 3y ago
  That's sort of outside the threat model though, isn't it? If an attacker can install a root cert, the entire thing is compromised. If you're concerned about that and want to pin, why have a chain of trust at all? Couldn't you just embed self-signed certs in the binary at that point? If you mean preventing users from clicking through the SSL warnings in a browser if they're being MITM'd, that makes sense to me.
  - toast0 3y ago
    > If you're concerned about that and want to pin, why have a chain of trust at all? Couldn't you just embed self-signed certs in the binary at that point? Not if you need to serve https traffic to clients and browsers from the same servers / same hostnames. > If you mean preventing users from clicking through the SSL warnings in a browser if they're being MITM'd, that makes sense to me. That comes from HSTS, not from cert pinning. Cert pinning in browsers is only available if you can convince the browser to include it in their static lists, which means you've got to be big... so that is what it is.
    - jcalvinowens 3y ago
      > Not if you need to serve https traffic to clients and browsers from the same servers / same hostnames That's what I was getting at, that makes sense to me. > That comes from HSTS, not from cert pinning. HSTS is a terrible half assed solution that relies on adding domains to magical predistributed lists. I wouldn't trust it if I cared enough about MITM to go to all this trouble.
      - toast0 3y ago
        > HSTS is a terrible half assed solution that relies on adding domains to magical predistributed lists. I wouldn't trust it if I cared enough about MITM to go to all this trouble. Sure, but cert pinning in browsers is done with the same magical redistributed lists; it's just even harder to get them changed.

Absolutely, I agree with everything you said. Pinning is not an effective anti-reverse-engineer technique. It's just annoying obfuscation to anybody who knows what they're doing.

toast0 3y ago

Pinning isn't really for anti-revere-engineering. It does discourage some reverse engineers, which is a bonus. But it's main purpose is to protect data integrity between the client and the server --- there's plenty of cases of CAs in system root stores that issued certs that could be used to intercept and manipulate traffic. There's also plenty of cases where something installed on the user's device adds itself to the system root store and intercepts traffic with the intent of passing it through but does not do so correctly and causes hard to diagnose errors. A pinned cert makes it easy to detect these MITMs and refuse to work if they're in place. A dedicated reverse engineer is "just" going to patch out the pin, and go on with their day, no big deal. But ISP MITM or corporate MITM or on device MITM is going to be stopped, and that's worthwhile.

jcalvinowens 3y ago
That's sort of outside the threat model though, isn't it? If an attacker can install a root cert, the entire thing is compromised. If you're concerned about that and want to pin, why have a chain of trust at all? Couldn't you just embed self-signed certs in the binary at that point? If you mean preventing users from clicking through the SSL warnings in a browser if they're being MITM'd, that makes sense to me.
- toast0 3y ago
  > If you're concerned about that and want to pin, why have a chain of trust at all? Couldn't you just embed self-signed certs in the binary at that point? Not if you need to serve https traffic to clients and browsers from the same servers / same hostnames. > If you mean preventing users from clicking through the SSL warnings in a browser if they're being MITM'd, that makes sense to me. That comes from HSTS, not from cert pinning. Cert pinning in browsers is only available if you can convince the browser to include it in their static lists, which means you've got to be big... so that is what it is.
  - jcalvinowens 3y ago
    > Not if you need to serve https traffic to clients and browsers from the same servers / same hostnames That's what I was getting at, that makes sense to me. > That comes from HSTS, not from cert pinning. HSTS is a terrible half assed solution that relies on adding domains to magical predistributed lists. I wouldn't trust it if I cared enough about MITM to go to all this trouble.
    - toast0 3y ago
      > HSTS is a terrible half assed solution that relies on adding domains to magical predistributed lists. I wouldn't trust it if I cared enough about MITM to go to all this trouble. Sure, but cert pinning in browsers is done with the same magical redistributed lists; it's just even harder to get them changed.