5 ms·

In my experience, the OS _does_ handle that automatically. If the app isn't verifying it, it's because they went out of their way to disable certificate validat

by knute 7y ago

In my experience, the OS _does_ handle that automatically. If the app isn't verifying it, it's because they went out of their way to disable certificate validation. Which is alarming.

iso1631 7y ago
What's the odds that the corporate network the developers are on does MITM https interception, and the only way they could get their app to work was to remove certificate validation
- RKearney 7y ago
  Very slim, as you can still verify the certificate chains up to a trusted root certificate and it’s trivial (and generally part of the enrollment process) to load the companies root CA on your device. We MITM and certificate validation works correctly.
  - lxgr 7y ago
    As far as I understand, this is no longer possible on modern iOS versions at least, except if the app developers explicitly disable that validation.
    - RKearney 7y ago
      You can pin your certificate in your app bundle such that your app only allows certificates you specify or ones signed by CA's you specify. That clearly isn't the case here. Normal iOS operation will verify the certificate chains up to a trusted root certificate and it is indeed possible to load your own trusted root CAs on to a device for purposes of MITM. Again, some apps may pin their own certificates, but that clearly wasn't happening in this example. I deal with this virtually every day.
  - WorldMaker 7y ago
    Except that there should be validations at even the Root CA level and most corporate MITM CAs don't pass those verifications either: - Is your root self-signed only? (Root CAs haven't been allowed to be self-signed only since roughly 2007 according to the principles of most browser root CA policies for public Roots. All public roots today are cross-signed among each other.) - Does your root certificate have a valid revocation chain? Can you query up-to-date revocation information on it? (Modern Roots all have to have working revocation information, and Root CAs have been revoked in internet history, you cannot blindly trust your device's Root CA store over time without up to date revocation lists.) Those are just two warnings I see most often from my dev tools on the MITM infrastructure I'm forced to deal with it. I know that this is compromising my security stance as a developer, and I know that turning off/ignoring those trade offs is a risk I directly pass on to users of anything I build. I've felt it a responsibility of professional ethics to pass on this concern to others in my company. I have debated many times whether if the right Root CA CVE or Self-Signed Certificate CVE comes across my dash if I will have to attempt to exercise the company's "Stop Work Authority" and refuse to continue development while being MITMed in a way that the company's security/safety infrastructure will not understand how to handle, but remains on my radar because I'm a professional and worrying about such things is my job. Running a Root CA is a huge responsibility, and still has a ton of risks for the "real" Root CAs. (Just look at the recent battle between browser security teams and Symantec, for instance, over generating bad certificates.) Running a corporate MITM has all the same responsibility, with an even worse risk if you get it wrong (your entire company's device footprint has a single point of failure). It's such an incredible vulnerability/risk that whatever tiny gain it gives companies in surveillance over SNI sniffing and endpoint/device-deployed auditing tools is never worth the risk of subjecting so many developers to badly MITMed developer environments, especially some of the developers most at risk (bank software, health software, etc) of passing on the software equivalent of a bad MITM plague given the worst happens. I cannot imagine the blasé with which Corporate America has MITMed itself can be seen as anything but an incredible folly, if not today than certainly tomorrow (hopefully not after the worst happens).
- AWildC182 7y ago
  Been there done that. Corporate IT often doesn't want to acknowledge that devs exist in the company because it's so much easier to just lock down the admin and marketing use cases. It's fucking scary how far they're willing compromise security internally and externally to avoid extra work and maintain control.
  - dzhiurgis 7y ago
    It's amazing how well such companies can repulse developers: - Everyone works on 8GB windows machine and sticky keyboard - Remote desktop - "You wanna install your IDE? Yeah contact IT, gonna take few days" - Can't install any of cli tools - Atlassian suite - Spend half a day in meetings - Scrum Then they complain how hard it is to get a good developers...
    - AdamJacobMuller 7y ago
      am I the only developer(ish) who likes JIRA?
      - notyourday 7y ago
        I think we found a yeti!
      - thwiv 7y ago
        Not at all. In my opinion, it sucks, but it's the best tool available for the job.
      - iso1631 7y ago
        The pros and cons of jira all depends how you use it
      - ansonhoyt 7y ago
        It has some friction in spots, but I like it a lot. A little configuration made it fit how we work. It does the job. However, I hear other companies like the configurability too...and their crappy processes were so easily configured that it became a crappy tool for their poor developers.
- alias_neo 7y ago
  MitM is pretty difficult if your app is validating, a lot of corps will install their in-house CA on your company issue devices so they can do this. If your software is using certificate pinning they can't even do this.
dastx 7y ago
Not necessarily, there are plenty of applications that use their own trusted root CAs and thus technically the app is validating it. Most popular example being Firefox. Often libraries have options to specify trusted root CAs as well as options to disable validation per host and/or globally. I've never come across any library that would have any of these options enabled by default. With that said, apps like banks should still not be putting trust into the OS or anything else. Certificate pinning is a good and should be utilised, especially for sensitive systems such as banks' apps.
- tialaramex 7y ago
  Historically it was very common to default disable or entirely omit essential checks. CWE-297 https://cwe.mitre.org/data/definitions/297.html https://cwe.mitre.org/data/definitions/297.html is about this common mistake. The happy path is invariably well tested and doesn't show this, unhappy paths often use garbage self-signed certs which fail non-host based checks and so those behave as expected too. Testing usually misses the host mismatch check. OpenSSL for years only provided some fairly hairy code if you actually wanted to do dnsName matching, which you absolutely should do. What that means is, lots of software was written (say, 10+ years ago) in which OpenSSL is checking that your peer has a "real" certificate but it doesn't care which one. A certificate for we-are.literally-thieves.example ? Cool, that's issued by a trusted CA and so it's fine. Oh you thought you were connecting to my-real-bank.example? You didn't ask me to check the name on the certificate and I don't bother providing a sensible API to do so anyway. Here's their actual documentation: > Versions prior to 1.0.2 did not perform hostname validation. Version 1.0.2 and up contain support for hostname validation, but they still require the user to call a few functions to set it up. Modern (1.1 onward) releases of OpenSSL provide a sane API which checks names you give it, so if you tell OpenSSL to connect to my-real-bank.example it realises you don't think certificates for other names are OK. But the old ones didn't do that and the ones 10+ years ago expected you to grok PKIX (the Internet's agreed way of coercing the X.509 standard intended for the X.500 series Directory into a way to certify things on the Internet) or else give up.
alias_neo 7y ago
It's not the same as pinning though. The device trusts that a cert was signed by _any_ CA on your phone, not necessarily the one that really issued the one you expect. So, if my company installed a CA on my phone that they issued in-house, and MiTM my traffic, they can spoof certs and most software will accept it. To be really safe, you should pin the certificate to ensure that your code only trusts a specific certificate or specific authority, so, for e.g. it was signed by Let's Encrypt X with fingerprint Y and not, say, Digicert Z with fingerprint A. If you're writing the backend and frontend, yor could go one step further and embed your own CA in the app and follow secure practice for managing the private key and issuing certificates to your infrastructure.
- tialaramex 7y ago
  Pinning is a serious step, there's a lot of opportunity for a foot gun. You absolutely need to decide up front what the intended behaviour for your app is when the pin is invalid. Don't say "That will never happen" because it will happen. Maybe the client is happy that their app simply does not work if the pin condition isn't satisfied. A bank might feel that way for example. But if it's a surprise I guarantee they aren't going to be happy and that means you did a bad job. Building your own PKI is always potentially the safest option, and in practice it will usually be the least safe and most unreliable. The main attraction of your own PKI should not be the safety/ security you likely won't actually achieve in practice but other conveniences. For example your PKI can issue a 20 year cert. Maybe it shouldn't, but it can and that might work better for you than certificates which expire and introduce exciting last minute changes.
  - alias_neo 7y ago
    Yes, I agree with all of the above. We specialise in this sort of thing at my work, I'm not suggesting anyone does this without first understanding the risks you mention above as well as the long term commitment required. But done right, it is the most secure approach.

by knute 7y ago

In my experience, the OS _does_ handle that automatically. If the app isn't verifying it, it's because they went out of their way to disable certificate validation. Which is alarming.

iso1631 7y ago

What's the odds that the corporate network the developers are on does MITM https interception, and the only way they could get their app to work was to remove certificate validation

RKearney 7y ago
Very slim, as you can still verify the certificate chains up to a trusted root certificate and it’s trivial (and generally part of the enrollment process) to load the companies root CA on your device. We MITM and certificate validation works correctly.
- lxgr 7y ago
  As far as I understand, this is no longer possible on modern iOS versions at least, except if the app developers explicitly disable that validation.
  - RKearney 7y ago
    You can pin your certificate in your app bundle such that your app only allows certificates you specify or ones signed by CA's you specify. That clearly isn't the case here. Normal iOS operation will verify the certificate chains up to a trusted root certificate and it is indeed possible to load your own trusted root CAs on to a device for purposes of MITM. Again, some apps may pin their own certificates, but that clearly wasn't happening in this example. I deal with this virtually every day.
- WorldMaker 7y ago
  Except that there should be validations at even the Root CA level and most corporate MITM CAs don't pass those verifications either: - Is your root self-signed only? (Root CAs haven't been allowed to be self-signed only since roughly 2007 according to the principles of most browser root CA policies for public Roots. All public roots today are cross-signed among each other.) - Does your root certificate have a valid revocation chain? Can you query up-to-date revocation information on it? (Modern Roots all have to have working revocation information, and Root CAs have been revoked in internet history, you cannot blindly trust your device's Root CA store over time without up to date revocation lists.) Those are just two warnings I see most often from my dev tools on the MITM infrastructure I'm forced to deal with it. I know that this is compromising my security stance as a developer, and I know that turning off/ignoring those trade offs is a risk I directly pass on to users of anything I build. I've felt it a responsibility of professional ethics to pass on this concern to others in my company. I have debated many times whether if the right Root CA CVE or Self-Signed Certificate CVE comes across my dash if I will have to attempt to exercise the company's "Stop Work Authority" and refuse to continue development while being MITMed in a way that the company's security/safety infrastructure will not understand how to handle, but remains on my radar because I'm a professional and worrying about such things is my job. Running a Root CA is a huge responsibility, and still has a ton of risks for the "real" Root CAs. (Just look at the recent battle between browser security teams and Symantec, for instance, over generating bad certificates.) Running a corporate MITM has all the same responsibility, with an even worse risk if you get it wrong (your entire company's device footprint has a single point of failure). It's such an incredible vulnerability/risk that whatever tiny gain it gives companies in surveillance over SNI sniffing and endpoint/device-deployed auditing tools is never worth the risk of subjecting so many developers to badly MITMed developer environments, especially some of the developers most at risk (bank software, health software, etc) of passing on the software equivalent of a bad MITM plague given the worst happens. I cannot imagine the blasé with which Corporate America has MITMed itself can be seen as anything but an incredible folly, if not today than certainly tomorrow (hopefully not after the worst happens).
AWildC182 7y ago
Been there done that. Corporate IT often doesn't want to acknowledge that devs exist in the company because it's so much easier to just lock down the admin and marketing use cases. It's fucking scary how far they're willing compromise security internally and externally to avoid extra work and maintain control.
- dzhiurgis 7y ago
  It's amazing how well such companies can repulse developers: - Everyone works on 8GB windows machine and sticky keyboard - Remote desktop - "You wanna install your IDE? Yeah contact IT, gonna take few days" - Can't install any of cli tools - Atlassian suite - Spend half a day in meetings - Scrum Then they complain how hard it is to get a good developers...
  - AdamJacobMuller 7y ago
    am I the only developer(ish) who likes JIRA?
    - notyourday 7y ago
      I think we found a yeti!
    - thwiv 7y ago
      Not at all. In my opinion, it sucks, but it's the best tool available for the job.
    - iso1631 7y ago
      The pros and cons of jira all depends how you use it
    - ansonhoyt 7y ago
      It has some friction in spots, but I like it a lot. A little configuration made it fit how we work. It does the job. However, I hear other companies like the configurability too...and their crappy processes were so easily configured that it became a crappy tool for their poor developers.
alias_neo 7y ago
MitM is pretty difficult if your app is validating, a lot of corps will install their in-house CA on your company issue devices so they can do this. If your software is using certificate pinning they can't even do this.

dastx 7y ago

Not necessarily, there are plenty of applications that use their own trusted root CAs and thus technically the app is validating it. Most popular example being Firefox. Often libraries have options to specify trusted root CAs as well as options to disable validation per host and/or globally. I've never come across any library that would have any of these options enabled by default. With that said, apps like banks should still not be putting trust into the OS or anything else. Certificate pinning is a good and should be utilised, especially for sensitive systems such as banks' apps.

tialaramex 7y ago
Historically it was very common to default disable or entirely omit essential checks. CWE-297 https://cwe.mitre.org/data/definitions/297.html https://cwe.mitre.org/data/definitions/297.html is about this common mistake. The happy path is invariably well tested and doesn't show this, unhappy paths often use garbage self-signed certs which fail non-host based checks and so those behave as expected too. Testing usually misses the host mismatch check. OpenSSL for years only provided some fairly hairy code if you actually wanted to do dnsName matching, which you absolutely should do. What that means is, lots of software was written (say, 10+ years ago) in which OpenSSL is checking that your peer has a "real" certificate but it doesn't care which one. A certificate for we-are.literally-thieves.example ? Cool, that's issued by a trusted CA and so it's fine. Oh you thought you were connecting to my-real-bank.example? You didn't ask me to check the name on the certificate and I don't bother providing a sensible API to do so anyway. Here's their actual documentation: > Versions prior to 1.0.2 did not perform hostname validation. Version 1.0.2 and up contain support for hostname validation, but they still require the user to call a few functions to set it up. Modern (1.1 onward) releases of OpenSSL provide a sane API which checks names you give it, so if you tell OpenSSL to connect to my-real-bank.example it realises you don't think certificates for other names are OK. But the old ones didn't do that and the ones 10+ years ago expected you to grok PKIX (the Internet's agreed way of coercing the X.509 standard intended for the X.500 series Directory into a way to certify things on the Internet) or else give up.

alias_neo 7y ago

It's not the same as pinning though. The device trusts that a cert was signed by _any_ CA on your phone, not necessarily the one that really issued the one you expect. So, if my company installed a CA on my phone that they issued in-house, and MiTM my traffic, they can spoof certs and most software will accept it. To be really safe, you should pin the certificate to ensure that your code only trusts a specific certificate or specific authority, so, for e.g. it was signed by Let's Encrypt X with fingerprint Y and not, say, Digicert Z with fingerprint A. If you're writing the backend and frontend, yor could go one step further and embed your own CA in the app and follow secure practice for managing the private key and issuing certificates to your infrastructure.

tialaramex 7y ago
Pinning is a serious step, there's a lot of opportunity for a foot gun. You absolutely need to decide up front what the intended behaviour for your app is when the pin is invalid. Don't say "That will never happen" because it will happen. Maybe the client is happy that their app simply does not work if the pin condition isn't satisfied. A bank might feel that way for example. But if it's a surprise I guarantee they aren't going to be happy and that means you did a bad job. Building your own PKI is always potentially the safest option, and in practice it will usually be the least safe and most unreliable. The main attraction of your own PKI should not be the safety/ security you likely won't actually achieve in practice but other conveniences. For example your PKI can issue a 20 year cert. Maybe it shouldn't, but it can and that might work better for you than certificates which expire and introduce exciting last minute changes.
- alias_neo 7y ago
  Yes, I agree with all of the above. We specialise in this sort of thing at my work, I'm not suggesting anyone does this without first understanding the risks you mention above as well as the long term commitment required. But done right, it is the most secure approach.