Well, I blathered on for all of that and didn’t actually really describe what cert pinning is.
:/ Sorry about that. This [1] is a pretty decent tl;dr version from stack exchange. “Typically certificates are validated by checking the signature hierarchy; MyCert is signed by IntermediateCert which is signed by RootCert, and RootCert is listed in my computer's "certificates to trust" store. Certificate Pinning is where you ignore that whole thing, and say trust this certificate only or perhaps trust only certificates signed by this certificate. So for example, if you go to google.com, your browser will trust the certificate if it's signed by Verisign, Digicert, Thawte, or the Hongkong Post Office (and dozens others). But if you use (on newer versions) Microsoft Windows Update, it will ONLY trust certificates signed by Microsoft. No Verisign, no Digicert, No Hongkong Post office.” The concept of a Man in the Middle attack is that the attacker can pretend to be the server your app is trying to connect to securely or even sit in between passing traffic to the server after inspecting it unsecured (passwords, credit card or banking details, etc). One of the ways they do this is with a SSL certificate signed by a different authority to the one your server’s certificate is signed by. Still valid as far as the browser (or webView) is concerned, just not YOUR server’s certificate. This OWASP article [2] is a much more in depth look at the issue, and there is also a good article by Moxie Marlinspike [3] about securing mobile apps that mentions certificate pinning [4] as one of the solutions. 1. http://security.stackexchange.com/a/29990 2. https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning 3. http://www.thoughtcrime.org/blog/authenticity-is-broken-in-ssl-but-your-app-ha/ 4. http://www.thoughtcrime.org/blog/authenticity-is-broken-in-ssl-but-your-app-ha/#option_2_trust_but_verify On 14 Jan 2014, at 6:29 am, Brian LeRoux <b...@brian.io> wrote: > So, sort of like CRSF tokens except the other way around. ??? > > I might be misunderstanding but would it not be better to treat the server > as trusted and the client generally as untrusted. Given there is no cross > platform key stores the certs are effectively plaintext (but I could be > misunderstanding the impl). > > > On Sun, Jan 12, 2014 at 3:21 AM, Tommy-Carlos Williams > <to...@devgeeks.org>wrote: > >> TL;DR: I am proposing to add certificate pinning at least to iOS and >> Android, and help on any implementations for other platforms in any way I >> can. >> >> (Longer version) >> >> There is an existing issue for certificate pinning [1] from back in May of >> 2013 and it's something that I need for all of our apps and even any I >> might make for myself in the future. >> >> The last year or two have seen a pretty serious rise in both actual >> exploits and awareness around the topic of security. There was an article >> tweeted around recently about someone auditing mobile bank apps and found >> that "40% of the audited apps did not validate the authenticity of SSL >> certificates presented. This makes them susceptible to Man in The Middle >> (MiTM) attacks" [2]. >> >> If certificate pinning is something good, and we can make it easy to >> implement, surely that would be a good thing? The whitelist is all well and >> good, but most people are probably leaving the default "*" and even if they >> didn't, it wouldn't protect them from MitM attacks. >> >> There *is* an existing plugin that attempts to do this for Cordova / >> PhoneGap [3][4], but it has a pretty massive and fairly obvious flaw. It >> simply checks the certificate then reports back in its callback. At first >> this might seem OK, but as someone pointed out in an issue [5], an attacker >> "could wait until the server is validated before adding the MITM server, >> circumventing the security check". I am no security expert, so if I could >> think of a way to get around this, then it's not very secure. >> >> What I am proposing, is adding certificate pinning to Cordova itself so >> that the *actual* requests are checked (much like the whitelist). Not some >> initial request, or having to try and do two requests for every request >> (still leaving open the hole I spoke of above). >> >> I am looking for buy-in from the list, but I am also interested in >> discussion on the best way to do it (and test it). >> >> My initial proposal is to use SHA1 fingerprints (much like Eddy's plugin >> above [6]) as opposed to trying to get devs to embed an entire cert file in >> their app. The easier it is to use the more likely people are to use it. If >> they can get the fingerprint from any site they want to safely access by >> simply using Chrome/Safari/etc, or a basic cli command, that would be best. >> I envisage devs being able to even pin the certs for third party services >> like Parse etc. >> >> A simple config.xml directive with key/value pairs of any >> hosts/fingerprints should be all a dev needs to use this feature. >> >> - tommy >> >> >> >> 1. https://issues.apache.org/jira/browse/CB-3498 >> 2. >> http://blog.ioactive.com/2014/01/personal-banking-apps-leak-info-through.html >> 3. >> http://www.x-services.nl/certificate-pinning-plugin-for-phonegap-to-prevent-man-in-the-middle-attacks/734 >> 4. https://github.com/EddyVerbruggen/SSLCertificateChecker-PhoneGap-Plugin >> 5. >> https://github.com/EddyVerbruggen/SSLCertificateChecker-PhoneGap-Plugin/issues/5 >> 6. >> https://github.com/EddyVerbruggen/SSLCertificateChecker-PhoneGap-Plugin#3-usage
