Remove checkInCertChain

[EddyVerbruggen]

Because this is a feature that doesn't offer a secure protection against MitM attacks. I know that folks use this with that fact in mind but I don't want to actively promote such usage. Use plugin version 4.0.0 or lower if you need to nonetheless.

[cvillerm]

Why is this considered as not secure? Pinning to a specific Certificate Authority (one that you trust because you specific it specifically) was a way to ensure that only certificates issued by a specific CA were trusted.
The main problem with certificate chain validation and MiTM is that:

1. You don't necessarily know what CAs are trusted by default by your OS and if one of these CAs becomes compromised, you may not know it and, even if you know it, you rely on an OS update to have such a root CA removed from the default trusted list.
2. Another potential issue is that it may happen for a non advanced user to trust a new CA manually, because they were "invited" (by a hacker) to trust it and the user didn't understand the warnings displayed on his mobile device.

In both these cases, pinning to a specific CA wouldn't be impacted by such other CAs.

Now, what can happen:

1. The CA you trusted so much becomes compromised. You will have to create a new certificate for your server, with another CA, and you will have to republish your application.This isn't different or less secure that pinning to the server certificate itself.
2. Your server certificate became compromised. Even if the so-trusted CA could add this server certificate in its CRL, this plugin isn't checking for this. Client-side CRL checking isn't completely safe anyway as a hacker could intercept and cancel all such CRL/OSCP checks, what often (and unfortunately) results in the client to consider the certificate Ok, by default. In this hopefully rare case, the fallback option may be to have a new server certificate created and the mobile application republished by pinning to the server certificate itself. At least, until the server certificate was compromised (again, a rare case), your application didn't have to be republished just because your server certificate had to be renewed.

I understand that an old version of this plugin can be used to continue and use this option, but this won't allow new features coming with new versions to be used, unless a custom branch is created.

[EddyVerbruggen]

@cvillerm If you want to discuss it with the person why brought this to my attention then I'll send you his email address. Please let me know if you want to.

[cvillerm]

@EddyVerbruggen, why not. What also about involving this person in this discussion?

[ikoz]

Hey @cvillerm, no need for email, we can chat here. The details of the vulnerability are now public: https://www.cigital.com/blog/ineffective-certificate-pinning-implementations and a cve has been assigned for the exact same issue on a different library (CVE-2016-2402)

SSLCertificateChecker-PhoneGap-Plugin is one of the affected libraries/apps.

Your points about CA pinning are correct; doing CA pinning is not inherently insecure. It just leaves a wider attack surface than doing end-entity pinning, but is still much better than not pinning at all.

The devil is in the detail though; implementation matters.

The way CA pinning was implemented in this library (and several others) was insecure, not CA pinning itself as a practice. Fixing the code while following the same basic implementation strategy while maintaining compatibility with multiple Android versions is not trivial because the available Java APIs do not help. Thus @EddyVerbruggen decided to remove the feature.

Using version 4.0.0 or lower of this library and setting checkInCertChain = True results in a completely ineffective SSL pinning control that can be easily and remotely bypassed, thus offering no protection at all.

[cvillerm]

Hi @ikoz, thanks for providing these details in this discussion. This is indeed helping everybody to learn. Until this core library is fixed, I understand now how this can indeed be a security breach.