How do you secure your iOS apps' network connections? Is it sufficient to simply use HTTPS in an NSURL object? The short answer is it depends. For sure, some recent attacks have eroded the trust we can place in the venerable SSL or TLS standards, but we're also not ready to just throw them out either.
It turns out you actually have numerous options available, depending on your app's needs. For starters, if you're using NSURL to make your HTTP connections, you can quickly change it to an SSL encrypted network session by simply changing the URL to HTTPS://...
That should provide you with basic protection against eavesdropping (and a few other network nasties) quickly and easily. But is it enough?
To understand that, let's consider a bit more what actually happens in an SSL protected network socket. When iOS (via NSURL) sees an SSL certificate from a server, it verifies two things: 1) is the certificate signed by a root certificate authority (CA), and 2) does the server's name (via DNS) match the name presented in the SSL certificate? Now, that combination might sound adequate, but there is actually a loophole or two remaining.
A sufficiently resourced adversary with access to the soft under belly of DNS as well as access to one or more CAs can still trick your app into accepting a connection you wouldn't otherwise want. In an extreme case, this could result from a successful man in the middle (MITM) attack.
So, for some cases, we might want to do more than just SSL. We might, for example, want to verify that a specific CA signed the server key. We might want to check that it is precisely the right server key that has been presented, using "certificate pinning".
Each of these things is achievable, but they require us to dig deeper than just using USURL with an HTTPS URL. They also have pros and cons -- cert pinning, for example, isn't going to work with many network proxies that a lot of corporate LANs require.
We'll discuss these options, along with code examples, at our Mobile App Sec Triathlon in November. Hope to see you there, ready to discuss so you can best understand what course of action is best for your app and its users.
Cheers,
Ken
No comments:
Post a Comment