As we heard this year's WWDC, at the end of 2016, Apple will make ATS mandatory for all developers who hope to submit their apps to the App Store. http://9to5mac.com/2016/06/15/ats-https-ios-apps/
http://www.cso.com.au/article/577197/apple-tells-ios-9-developers-use-https-exclusively/
It is understandable in cases where privacy, encryption (...) is a factor. But what about simple (news...) feeds, API-s whare it is not the case?
What about simple json or rss feeds? E.g. I have a very simple public json feed that can be called without any authorization, will it also need https? And what about simple RSS feeds? Huge majority of them communicates now via http. What about downloading image files from the web in an app?
Thanks in advance!
This is very rapidly becoming "the new normal." (Did you notice that even WikiPedia now uses https connections to their site?) Non-encrypted communications can be effortlessly intercepted, e.g. in the coffee shops and public places where so many people routinely find themselves. The problem is even more severe now that "free public WiFi" is available in "ordinary" stores and Wal-Marts, and people have their phones set to automatically connect to any of them. (People do not realize how insecure they are! But, they're learning ...)
The most appropriate solution, then, is to "encrypt everything." And so, this is what Apple is now mandating.
Yes, even "routine" communications, news-feeds and such. All of the traffic that passes through the airwaves will be encrypted.
Remember, also, that these techniques not only secure the communication, but are capable of identifying the sender and the receiver to one another through mutually-held certificates. (Web sites don't always use client-identification, although they can, and apps definitely should.) This, if used properly, will close a very big headache-hole for servers, because they now will know just who they are talking to. Client software can trust that they are talking to the right server, and that their communications are "received as tendered."
"Android or iOS or Windows or what-have-you," you should be doing this. Every mobile device implements SSL and possibly other encryption stacks. Do not send anything over air-waves "in the clear."
A "simple feed", in some country, can kill you. Protect your users, encrypt everything.
Related
After reading this article on Ars Technica I started looking for a way to enable an encrypted, yet passwordless public network. It is probably not possible due to specifications which require a certain number of characters and OSs complying with them, but what about accepting any password?
It will most definitely require custom scripting or even modifying the sources, so I've chosen OpenWRT to try this out. The relevant sources can be found here and here, which are used for building the wpad, hostpad and wpa-supplicant packages. By default OpenWRT uses wpad-mini (suffix mini means an absence of the WPA Enterprise support).
One of my thoughts was to also try WPA Enterprise for this purpose. Would it be possible to write a simple script to mimic the Radius server response, being always positive, as if credentials were correct?
Another aspect of this question is security. If accepting any password was possible, wouldn't it mean that anyone could trick my device to connect to an AP with the same name, as say, I use at home, and have control over the traffic? This can be a very serious issue and it is better to talk about it publicly than just pretending that if we don't publish a way to do this, no one else will do the same on black markets or in governments.
upd: Would it be possible to use a simple captive portal to 'negotiate' encryption, ideally, without any user interaction apart of opening the page? Naturally, it won't be WPA. Here is a good list of captive portal solutions for OpenWRT. A precaution: with the current OS-level implementations this wouldn't prevent leaking unencrypted data before the negotiation happens. But since OSs already recognize captive portals and display notifications, it should be possible to add a security feature to prevent any data transfers before passing the captive portal.
I'm building an iOS app for a client that allows users to pay a subscription and unlock additional content within the app. Part of the additional content will be videos which need to be streamed from a server... but I'm not sure whether we should use a hosting service (like Amazon CloudFront or Wowza, perhaps?) or roll our own solution.
Have any of you had experience with either of these options? I looks like this is supported natively by nginx, which we're currently using as our rProxy, but I'd like to hear some thoughts about that. I would be somewhat concerned about saturating our server's 1Gb network connection too...
Whatever the solution, we must be able to verify a person's account before they can access the video content. Variable bitrate is also desirable, and the ability to support >500 concurrent users. This company is also a new startup, so subscription costs are an important factor.
It is usually best to deploy streaming-specific software or services instead of generic HTTP servers such as Nginx. For Wowza, as an example, here's a quick list of features for this type of workflow.
Performance and scalability. You can do a quick comparison on playing back concurrent streams (using load test tools) and see what kind of load can be handled by an HTTP server vs Wowza.
Monitoring. Statistics collection is also integrated with Wowza, which may prove beneficial for start-up companies that need to leverage this kind of data mining.
Security. Wowza also has several options that you can use, such as Secure Token. For example, you can configure your mobile app to query the user's IP address once you determine that they are authorized to receive the stream. You can then generate a hash token based on this IP address and the stream they are authorized for, and only allow playback with the valid token. You can also expire these tokens.
Manager UI. Not as attractive for developers/sys admins, but users can take advantage of a relatively intuitive UI.
Extensibility. Wowza has REST and Java API that can allow you to add custom modules or integrate third-party systems. For example, you can use a custom module that monitors stream connection time, and cuts off any connections that are longer than x number of hours.
I'm designing some OSX/iOS apps that I'd like to share a resource to be hosted on a webserver. I would like to have some sort of web app or script that can store a list of subscribers, and to notify them when the resource is updated. (The obvious goal here is to avoid having every app poll the webserver for updates.)
The only trick here is that I'd like a significant number of clients (say, a dozen) to be subscribed for updates on a 24/7 basis. I'm not sure if it's a good idea for all of the clients to maintain a live connection... I imagine that many web service providers will be happy about their webserver maintaining a dozen persistent connections (especially if they're virtually always idle).
(Edit) I looked into the Apple Push Network Service (APNs), but it's not the right solution for my problem. APNs requires an Entrust SSL Certificate, and some heavy interaction with the Apple Push Network service. My project is much simpler and more lightweight: I just need a script that says, "Upon receiving data from Device A, push it out to Devices B/C/D" (presuming those devices are somehow accessible... either through a persistent connection or some other technique).
What's the absolute simplest way of providing this mechanism?
The "simplest way" probably means different things to different people. If you're not a fan of locking yourself into third party services then there's a veritable plethora of app frameworks and open source tools you could use to build something yourself. But this is hardly 'simple' if web app development isn't your strong point.
There are several 'off the shelf' services available to do real-time messaging on iOS: bear in mind I'm just listing the ones I know from memory, there are other alternatives. Pusher and PubNub both offer real-time messaging services for mobile apps, along with ready to go SDKs. You can interface with them to send messages bi-directionally via sockets (so similar to how APNS works, but with considerable more control).
You could use these services with your own device/user management system, or you could use a 'backend as a service' provider such as Parse or Stackmob - you may not need this step, it depends how complex your intended app/integration is.
XMPPFramework has a publish–subscribe module (for XEP-0060) which works with most XMPP servers. I've even adapted it to work with Chat Server which comes with Snow Leopard.
If you already have an XMPP server this might be worth doing; otherwise it's kind of a heavyweight solution.
I'm familiar with SOAP and Webservices for peer-to-peer or client/server messaging on other platforms. What is the Apple equivalent for messaging?
I'm trying to put together an application server that will manage a collaborative work environment. It will have an average of 200 and maximum of 1000 mobile clients on a LAN. For example, one Mac and 200 iPhones. I'm planning to use Apple's Enteprise approach to distribute our private (commercial) app to each of our iPhones clients.
The server can push configuration settings to each client. The server will also push small sets of data to the clients. The clients will perform tasks on this data locally, and eventually report back status to the server. The clients can request more data sets from the server. These exchanges can be managed asynchronously.
There is also be a need to have synchronous exchanges for critical processes. This is rare, but it is a requirement.
The data that needs to be exchanged is reasonably small. These client/server processes are time dependent, so performance is critical requirement.
The network won't be shared, but needs to be tightly controlled (and fast). E.g. it can be Bonjour if there is a compelling reason for that.
I'm looking for a recommendation on which components of the Mac/iOS SDKs to leverage. Please leave 3rd party software out of this discussion. I must know what Apple already offers and what gaps exist before considering outside software. Thanks.
If you are only going to be using Mac and iOS products then Bonjour is really your best bet. There are a ton of native ways to transmit data in either byte or object forms.
There were a couple great videos from WWDC 2012 showing what the new Xcode can do to create client and server applications. It is under NDA, but you may want to take a look there: https://developer.apple.com/videos/wwdc/2012/.
Also you said you did not want third party, any particular reason? Would you use an open source layer on top of Bonjour?
What are the best practices to add sensitive data to the iOS application?
For sensitive data I mean a key or token to communicate with some external server.
Can we compile a certificate in the app, and iOS can remove it on installation?
I feel like we can not really 100% guarantee security of it, but what is the best practice layer we can add.
There is no mechanism that will ensure to a server that only your application is allowed to speak to it. So if that is your goal, then it is unsolvable. This has been talked to death on SO. Just a few:
Secure Communication Between iPhone and Server?
Store an encryption key in Keychain while application installation process
Secure https encryption for iPhone app to webpage
(And the many other links within those postings.)
And elsewhere:
Obfuscating Cocoa
You cannot authenticate devices or software. You can only authenticate users. That means a login. Without a login that is partially stored in the user's brain (or at least in something separate from their iPhone), it's just obfuscation.
Now, that doesn't mean that obfuscation is useless. It isn't. You can get some mileage out of a simple authentication token (like a client key), but don't expect it to survive an attack. That doesn't mean you shouldn't do it; it just means you shouldn't spend a lot of time/money on it since it will fail pretty fast.
In no cases should you implement something that ticks off paying customers. Read the several threads linked above (and the several threads linked from those threads). If after that, you still absolutely need a solution, then you'll need to hire someone to keep track of the cracks and fix them every time a new one comes out. It will never stop.