3 ms·

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 lo

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).

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).