In this tutorial, you’ll learn how to prevent man-in-the-middle attacks using SSL Pinning and Alamofire. You’ll use the Charles Proxy tool to simulate the man-in-the-middle attack.
Nice follow-up after the Charles proxy tutorial, thanks
Very nicely done
Should note that it’s common to hash any certificates included in the app bundle and reverify the hash in the application code after loading them but before passing them on to your trust setup code.
Minor, but it’s another step in the PENTest security chain to ensure that the certificate you think you’re trusting is the one you actually included in the app in the first place, and hasn’t been replaced or otherwise compromised.
Similarly, you might encrypt or otherwise encode the raw text of the public key included in the app. Not absolute protection, to be sure, but it does make it harder to simply find and replace.
Showing Recent Messages
SWIFT_VERSION ‘5.0’ is unsupported, supported versions are: 3.0, 4.0, 4.2. (in target ‘Alamofire iOS’)
Thanks for the tutorial, I have a question.
In the Structure of a Digital Certificates there is the Valid To field:
Not Valid After Wednesday, 14 August 2019 at 14:00:00 Central European Summer Time
You need to compulsory update the app with a new Certificate before the Certificate is not longer valid or how do you manage it?
Xcode 10.2 compiles the projects as Swift 5 with no issues. Note this is Alamofire 5 beta that’s included in the project, not the current Alamofire 4.x release.
Pretty nice tutorial. I wonder if there is another way to validate you are connecting to the server you are meaning to without having to attach the server certificate (or public key).
I am thinking of cases where the servers vary a lot. With the described strategy it would mean that we have to know before hand all those severs and include the certs (or public keys) in the bundle, or keep updating the app with new updated certs in the bundle. And sometimes these approach does not scale.
You could set up a way to download the new cert from an external service if the one you have is invalid. Otherwise you could make cert pinning configurable, i.e. based on a specific configuration you could enable or disable it.
This can be for example done with public keys. Through a configuration service you can download (when the app launches, for example) all the keys you’ve configured and validate against those.
Thank you for your answer.
This tutorial is more than six months old so questions are no longer supported at the moment for it. Thank you!