5 ms·

Your app shouldn't suffer SSL's problems (2011)

44 points by tgragnato 9y ago

gcb0 9y ago
this ignores user trust. now the closed source application is impervious to mim attacks or bad CA operators but the user also have no way to validate the traffic comming out of their very own device. generic is good sometimes. and the generic solution already account for generic user/app local certificates just fine. no need to hide an extra one that can't be verified/update inside the app. that's kinda of an asshole move.
- tptacek 9y ago
  This doesn't make sense. Do you have the private key for Facebook's Digicert-signed certificate? No, you don't. So what difference does it make whether you get certificate trust from Digicert or from an anchor installed along with your mobile app?
  - saurik 9y ago
    ... because you essentially are always allowed to install your own custom root certificate when people use the system SSL support, even on iOS? (FWIW, I also feel like the implied solution here is wrong, but your analysis is worse.)
    - tptacek 9y ago
      What difference does that make? It's also annoying to test applications that don't honor system proxy settings. And?
tialaramex 9y ago
So, this is about six and a half years ago (December 2011) Distrust of the Web PKI (the Public Key Infrastructure for SSL/TLS on the Internet that basically falls out of what the Netscape Corporation built in the 1990s) was high and lots of people were sure better was possible. Moxie was one of them and so was I. So - what happened? Maybe somebody wrote a good article summarising, and will link it here, but otherwise here's a brief summary in two halves, plus a bonus 1. Web PKI trustworthiness improvements. The CA/B Forum Baseline Requirements have been tightened up somewhat, so that the accepted minimum standard is higher than it was. Google's Certificate Transparency work ensure we (the public) can see what they're up to, rather than relying on rumours and guesswork, and so we can insist they do what they've said they would before disaster strikes. The Mozilla project's mozilla.dev.security.policy, open to the general public, began to take its oversight role more seriously. 2. Alternatives proved trickier than anticipated. e.g. Pinning sounds great, and it works for Google, Apple, Microsoft. Most of the time. But it's a massive foot gun, and in some forms (HPKP) it's also a ransom mechanism; DANE leverages DNSSEC, but when you try to do that you find that a surprising number of users don't have working DNSSEC, indeed their DNS doesn't work properly even without DNSSEC; TOFU approaches which worked great for SSH in practice turn out not to suit the way ordinary users interact with the Web. Bonus: Some fraction of the people who expressed concerns like Moxie turned out to mainly, perhaps unconsciously, not want to pay $$$. Let's Encrypt almost incidentally (because it's automated and machines don't have wallets) is free at the point of use. It's surprising how many people who were absolutely certain they hated the Web PKI in principle came around to it once it was free...
- tptacek 9y ago
  You're talking about the Web PKI. Moxie is not talking about the Web PKI; he's pointing out that mobile apps don't need to rely on the Web PKI, because installing an app already involves deploying a trust anchor (the app itself), and you might as well exploit that to bootstrap trust with your servers rather than using CA signatures.
  - agwa 9y ago
    That's Option 1. In Option 2, Moxie suggests using the Web PKI, with pinning. I agree with tialaramex that this advice has not aged well. Most Web PKI experts would now advise against pinning and point to Certificate Transparency instead. Even Google, the pioneers of pinning that Moxie cites in his post, are moving away from pinning Google properties in Chrome.
    - tptacek 9y ago
      You're still talking about browsers. Moxie isn't: he's talking about mobile applications. There is little reason to rely on CAs, even with pinning, in a mobile application. You can simply make your own arrangements with your servers, since you control both ends of the connection. In that scenario, CAs add literally no value at all.
      - shawkinaw 9y ago
        Except that, IMO, I should be able to MITM the connection between an app on my phone and any server it’s talking to, for auditing purposes. In that case, CA/system trust-based systems let me do that relatively easily with a proxy. If the app sets up its secure connection with its own, uncustomizabe trust store, I can’t.
        tptacek 9y ago
        Appsec firms routinely test iOS applications with pinned certificates.
        9y ago

44 points by tgragnato 9y ago

gcb0 9y ago

this ignores user trust. now the closed source application is impervious to mim attacks or bad CA operators but the user also have no way to validate the traffic comming out of their very own device. generic is good sometimes. and the generic solution already account for generic user/app local certificates just fine. no need to hide an extra one that can't be verified/update inside the app. that's kinda of an asshole move.

tptacek 9y ago
This doesn't make sense. Do you have the private key for Facebook's Digicert-signed certificate? No, you don't. So what difference does it make whether you get certificate trust from Digicert or from an anchor installed along with your mobile app?
- saurik 9y ago
  ... because you essentially are always allowed to install your own custom root certificate when people use the system SSL support, even on iOS? (FWIW, I also feel like the implied solution here is wrong, but your analysis is worse.)
  - tptacek 9y ago
    What difference does that make? It's also annoying to test applications that don't honor system proxy settings. And?

tialaramex 9y ago

So, this is about six and a half years ago (December 2011) Distrust of the Web PKI (the Public Key Infrastructure for SSL/TLS on the Internet that basically falls out of what the Netscape Corporation built in the 1990s) was high and lots of people were sure better was possible. Moxie was one of them and so was I. So - what happened? Maybe somebody wrote a good article summarising, and will link it here, but otherwise here's a brief summary in two halves, plus a bonus 1. Web PKI trustworthiness improvements. The CA/B Forum Baseline Requirements have been tightened up somewhat, so that the accepted minimum standard is higher than it was. Google's Certificate Transparency work ensure we (the public) can see what they're up to, rather than relying on rumours and guesswork, and so we can insist they do what they've said they would before disaster strikes. The Mozilla project's mozilla.dev.security.policy, open to the general public, began to take its oversight role more seriously. 2. Alternatives proved trickier than anticipated. e.g. Pinning sounds great, and it works for Google, Apple, Microsoft. Most of the time. But it's a massive foot gun, and in some forms (HPKP) it's also a ransom mechanism; DANE leverages DNSSEC, but when you try to do that you find that a surprising number of users don't have working DNSSEC, indeed their DNS doesn't work properly even without DNSSEC; TOFU approaches which worked great for SSH in practice turn out not to suit the way ordinary users interact with the Web. Bonus: Some fraction of the people who expressed concerns like Moxie turned out to mainly, perhaps unconsciously, not want to pay $$$. Let's Encrypt almost incidentally (because it's automated and machines don't have wallets) is free at the point of use. It's surprising how many people who were absolutely certain they hated the Web PKI in principle came around to it once it was free...

tptacek 9y ago
You're talking about the Web PKI. Moxie is not talking about the Web PKI; he's pointing out that mobile apps don't need to rely on the Web PKI, because installing an app already involves deploying a trust anchor (the app itself), and you might as well exploit that to bootstrap trust with your servers rather than using CA signatures.
- agwa 9y ago
  That's Option 1. In Option 2, Moxie suggests using the Web PKI, with pinning. I agree with tialaramex that this advice has not aged well. Most Web PKI experts would now advise against pinning and point to Certificate Transparency instead. Even Google, the pioneers of pinning that Moxie cites in his post, are moving away from pinning Google properties in Chrome.
  - tptacek 9y ago
    You're still talking about browsers. Moxie isn't: he's talking about mobile applications. There is little reason to rely on CAs, even with pinning, in a mobile application. You can simply make your own arrangements with your servers, since you control both ends of the connection. In that scenario, CAs add literally no value at all.
    - shawkinaw 9y ago
      Except that, IMO, I should be able to MITM the connection between an app on my phone and any server it’s talking to, for auditing purposes. In that case, CA/system trust-based systems let me do that relatively easily with a proxy. If the app sets up its secure connection with its own, uncustomizabe trust store, I can’t.
      - tptacek 9y ago
        Appsec firms routinely test iOS applications with pinned certificates.
      - 9y ago