I am using a single https static URL in my iOS application. I want to secure that using ATS. I am confused which exception should be used in .plist file.
1-NSIncludesSubdomains
2-NSExceptionAllowsInsecureHTTPLoads
3-NSExceptionRequiresForwardSecrecy
4-NSExceptionMinimumTLSVersion
5-NSThirdPartyExceptionAllowsInsecureHTTPLoads
6-NSThirdPartyExceptionRequiresForwardSecrecy
7-NSThirdPartyExceptionMinimumTLSVersion
Thanks in advance
You don't need to add any flags in ATS to enable secure communication. ATS flags are used to exclude domains from requiring https communication.
Make sure your url you use starts with https and it will connect securely.
Now, there are more advanced things you can do, such as certificate pinning, but that doesn't involve ATS, and I'd recommend using something like Alamofire to help do all that configuration properly.
Related
I'm a relatively new programmer to backend security so very much in the dark about how to set up HTTPS. I'm currently writing an IOS app that is sending http requests to my public EC2 backend domain, however I'm trying to transition this to HTTPS. Right now the backend is running on the developmental Flask server using HTTPS with a self signed certificate. However the problem is that on the IOS app side, it rejects this as invalid so I'm unable to test HTTPS dependant features. I tried to use the domain exception with the infoplist and ip.xip.io but it still complains that someone could be pretending to be this address. Could someone list in a very systematic way how I should approach building this out,i.e are there any free CA's, do I need a cert from a CA, and how to go about properly connecting the app and backend with HTTPS using my ec2 public ip.
Perhaps the iOS app will authenticate properly using a free community certificate. Investigate free certificate authorities, like letsencrypt. There are several. These work like the commercial CAs such as GoDaddy.
Actually the easiest solution was to just use Ngrok
In production we will use a REST web service secured with SSL (HTTPS) while in development we're not using SSL (HTTP).
To allow HTTP communication we've configured our development hosts with NSTemporaryExceptionAllowsInsecureHTTPLoads set to true.
Is it considered acceptable to ship apps with this setting or is there a better way to do this? We weren't sure if Apple would object to this configuration.
Went with Roman's suggested approach and enabled ATS for debug but disabled it for all release builds. https://stackoverflow.com/a/32704702/47281
In my app, APIs provide the domains for images and videos during runtime and I need to allow these connections to be made. Using NSAllowsArbitraryLoads seems to be the only satisfactory thing I can do right now, but I would like to take advantage of ATS and only whitelist this short list of domains provided at runtime.
According to the App Transport Security Technote, all of these domains are set in the Info.plist, which is copied at compile time. Is it possible to allow HTTP or loosen TLS requirements during runtime for requests to these specific domains?
No, the ATS policy is defined at compile time. My guess is that it may be so that it becomes part of the signed application package and can't be tampered with.
In your case allowing insecure transfers generally wil be required. If the API endpoints you use support TLS then you can specific those domains as exceptions that require security in the policy file.
I'm fairly new to SSL and secure connections in general. What are the major steps required for an iOS app to talk to a server over a secure communications channel?
I'm aware that an SSL certificate will probably be necessary. I'm planning to purchase one from a trusted certificate authority. However I'm not sure if both the app and the server need certificates or if it's just the server. Also I'm not sure how to handle SSL errors. Perhaps there's a library that can help with this like ASIHTTPRequest or similar.
If you are using HTTPS as your protocol for communication and have valid certificates on your server all that should be required is changing your http:// to https:// on your client. For HTTP libraries a very popular option now is AFNetworking. It is a bit better maintained than ASI and has some nice block features not supported by ASI.
As far as SSL errors, it is usually a good idea to present the warnings to end users (through alert views or some other means). They could point to real security attacks (but more likely will point to miss configured or expired certificates).
I'm working on an ios application without authentication. Now I would like to protect my server API from calls other then my ios application. A possible solution would be to have the application generate a unique key (based on the appname and the signing), which is not stored on the device since this is the main problem. I could think off an application logic that does some protection combined with some file encryption but the problem is that somewhere something is stored (ex public key can be stored in keychain but still not safe for my API-hackers).
Anyone any tips/advice on how I can handle this ?
thanks in advance
In short, there is no 100% secure way to make sure that the request comes from your application, if the key is available to the iPhone, it's available to extract from the iPhone.
You can make it reasonably safe by calculating a key runtime from info in the application as you say and communicate it over SSL, but a determined attacker can always reverse engineer the key generation too.
What you want to do is employ mutually-authenticated SSL, so that your server will only accept incoming connections from your app and your app will only communicate with your server.
Here's the high-level approach. Create a self-signed server SSL certificate and deploy on your web server. You can use freely available tools for this, like keytool, and I think (but don't know for sure) that Apple includes a tool for this with the iOS SDK. Then create a self-signed client and deploy that within your application in a custom keystore included in your application as a resource. Configure the server to require client-side SSL authentication and to only accept the client certificate you generated. Configure the client to use that client-side certificate to identify itself and only accept the one server-side certificate you installed on your server for that part of it.
If someone/something other than your app attempts to connect to your server, the SSL connection will not be created, as the server will reject incoming SSL connections that do not present the client certificate that you have included in your app.