Categories
Deploy360 Transport Layer Security (TLS)

Apple to mandate TLS in 2017

One of the announcements at the last Apple Worldwide Developers’ Conference (WWDC16) was that Apple would require all apps in its App Store to support TLS 1.2. TLS is a protocol that encrypts data sent between applications over the Internet, and is therefore essential for ensuring that data being transmitted cannot be eavesdropped on.

The best known usage of TLS is in secure web browsing (using HTTPS) which can be visually checked using the padlock icon that appears in browsers when a secure session is established. Unfortunately, mobile apps are often less transparent about the security of their connections when they connect to a server, and it can be much harder to tell whether an app is using TLS.

Apple therefore introduced App Transport Security (ATS) in iOS 9, which forces apps to connect over a secure connection. Until now, it has been possible for apps to disable this so they can use non-TLS enabled services, but from some point in 2017 this will no longer be possible.

Apps were already supposed to have migrated to using ATS by 1 January this year, but with only 3% of the 200 most popular apps (including Facebook, LinkedIn and Skype) found to be fully compliant, Apple has announced an extension to this deadline. Nevertheless, if you’re an iOS app developer or operating services accessed by iOS apps, you need to be ensuring that you can support the ATS requirements over the coming months.

More Information:

Deploy360 also aims to help this process, so please take a look at our TLS section to understand why the use of TLS is important.

Categories
Deploy360 IPv6

Starting June 1, Apple Requires All iOS Apps To Work in IPv6-ONLY Networks

Apple iOS 9 logoBack at their June 2015 WWDC event, Apple announced that all iOS 9 applications must support IPv6. This week Apple declared that as of June 1 all apps submitted to the AppStore MUST support IPv6-only networking.  From Apple’s blog post:

At WWDC 2015 we announced the transition to IPv6-only network services in iOS 9. Starting June 1, 2016 all apps submitted to the App Store must support IPv6-only networking. Most apps will not require any changes because IPv6 is already supported by NSURLSession and CFNetwork APIs.

If your app uses IPv4-specific APIs or hard-coded IP addresses, you will need to make some changes.

As Apple continues to point out, the vast majority of application developers will not need to do anything to support IPv6.  If developers use the standard networking APIs provided by Apple, they should not experience any problems in an IPv6-only network.  It should “just work”.  It’s only when developers use IPv4-specific APIs or addresses that there is a problem.

Why This Matters

This is an extremely important step.  As I wrote last year after WWDC 2015, this requirement means that iOS apps will work in the IPv6-only networks that we are starting to see appear.

More than that, this requirement will drive millions of developers to test their apps in an IPv6-only network.  This kind of testing will increase basic knowledge developers have of IPv6 – and will lead to better networking knowledge all around.

Additionally, if the app connects back to a web site or service, this requirement may encourage developers to understand what they need to do to make that site / service reachable via IPv6. It seems that Apple may be testing for an “IPv6-only” network that also has IPv4-translation at the edge.  From Apple’s developer documentation:

“A DNS64/NAT64 network is an IPv6-only network that continues to provide access to IPv4 content through translation.”

So to meet the June 1 requirement, apps may only need to:

  1. work over IPv6 network connections; and
  2. use DNS over IPv6.

At the current time it appears that the site / service to which an application connects will NOT need to be reachable over IPv6 because of the ability to use IPv4 translation.  However, developers may want to explore what they need to do to be reachable over IPv6 as that may be simpler and faster than dealing with IPv4 translation.

Eventually the sites and services will need to be reachable over IPv6 – and so this requirement may drive more requests for IPv6 connectivity to ISPs and other hosting providers.

All in all it is a great move to help drive IPv6 usage!

Getting Help

Apple suggested that people read their developer documentation “Supporting IPv6 DNS64/NAT64 Networks” and watch the WWDC 2015 video “Your App and Next Generation Networks“.  I previously provided a summary of this video along with screenshots of the major points.

We would of course also suggest you visit our Start Here page to find IPv6 resources for your type of organization. Specifically for app developers we suggest:

The key point is to start NOW if you haven’t already, as any AppStore submissions after June 1 will require IPv6-only testing.

Thank you, Apple, for making this hard requirement!  It will only help as we continue to work to transition the Internet from the “beta” of IPv4 to the “production” IPv6 network!


More discussion of this topic:

 

Categories
IPv6

Starting June 1, Apple Requires All iOS Apps To Work in IPv6-ONLY Networks

Apple iOS 9 logoBack at their June 2015 WWDC event, Apple announced that all iOS 9 applications must support IPv6. This week Apple declared that as of June 1 all apps submitted to the AppStore MUST support IPv6-only networking.  From Apple’s blog post:

At WWDC 2015 we announced the transition to IPv6-only network services in iOS 9. Starting June 1, 2016 all apps submitted to the App Store must support IPv6-only networking. Most apps will not require any changes because IPv6 is already supported by NSURLSession and CFNetwork APIs.

If your app uses IPv4-specific APIs or hard-coded IP addresses, you will need to make some changes.

As Apple continues to point out, the vast majority of application developers will not need to do anything to support IPv6.  If developers use the standard networking APIs provided by Apple, they should not experience any problems in an IPv6-only network.  It should “just work”.  It’s only when developers use IPv4-specific APIs or addresses that there is a problem.

Why This Matters

This is an extremely important step.  As I wrote last year after WWDC 2015, this requirement means that iOS apps will work in the IPv6-only networks that we are starting to see appear.

More than that, this requirement will drive millions of developers to test their apps in an IPv6-only network.  This kind of testing will increase basic knowledge developers have of IPv6 – and will lead to better networking knowledge all around.

Additionally, if the app connects back to a web site or service, this requirement may encourage developers to understand what they need to do to make that site / service reachable via IPv6. It seems that Apple may be testing for an “IPv6-only” network that also has IPv4-translation at the edge.  From Apple’s developer documentation:

“A DNS64/NAT64 network is an IPv6-only network that continues to provide access to IPv4 content through translation.”

So to meet the June 1 requirement, apps may only need to:

  1. work over IPv6 network connections; and
  2. use DNS over IPv6.

At the current time it appears that the site / service to which an application connects will NOT need to be reachable over IPv6 because of the ability to use IPv4 translation.  However, developers may want to explore what they need to do to be reachable over IPv6 as that may be simpler and faster than dealing with IPv4 translation.

Eventually the sites and services will need to be reachable over IPv6 – and so this requirement may drive more requests for IPv6 connectivity to ISPs and other hosting providers.

All in all it is a great move to help drive IPv6 usage!

Getting Help

Apple suggested that people read their developer documentation “Supporting IPv6 DNS64/NAT64 Networks” and watch the WWDC 2015 video “Your App and Next Generation Networks“.  I previously provided a summary of this video along with screenshots of the major points.

We would of course also suggest you visit our Start Here page to find IPv6 resources for your type of organization. Specifically for app developers we suggest:

The key point is to start NOW if you haven’t already, as any AppStore submissions after June 1 will require IPv6-only testing.

Thank you, Apple, for making this hard requirement!  It will only help as we continue to work to transition the Internet from the “beta” of IPv4 to the “production” IPv6 network!


More discussion of this topic:

 

Categories
Encryption Improving Technical Security

Enough about Apple and Encryption: Let's talk system security

I want to share a perspective on system security.

My phone as a system

The Apple/FBI case revolves around a phone. Think of your own phone now.

When I look at my own phone I have rather sensitive information on it:

  • my calendar, which could be used to find out when to rob my house;
  • pictures of my kids that I do not want others to see;
  • a password manager which could be used to impersonate me anywhere in the virtual world;
  • content I do not want my wife, my boss, and my friends to know about;
  • a banking app and a Paypal app that could be used to make transfers to another account.

I need to be able to trust that thing. I am not alone in this – as an example, a report showed that 2,000 people in the UK each day realize that there is something on the phone that they just lost that could land them into some sort of trouble.

Let’s step away from phones – the arguments apply to all of our ICT devices, software or services. System for short.

From Encryption to System Security

Much of the focus of the debate so far has centered around law enforcement access to content, especially content that is stored on an encrypted phone. Yet, there is also a broader issue at stake: system security. Let’s take a device as an example of a system.

Device security is important because it protects against third parties gaining access to the device. Proper device security can prevent: modification of the software or firmware that makes the device work; and access to personal data stored on, and communications performed with, the device. It is intended to prevent any unauthorized party from using any of the functions of the device. Device security is enabled by many tools: encryption, authentication mechanisms (e.g. the passcode), specific forms of digital rights management, self-updating software, physical security such tamper proof chips, self destruction, etc.

Encryption is one of the more fundamental tools in the security toolbox because it is ubiquitously used to protect all sorts of communication and data, in phones, teller machines, car-keys, television boxes, DVD players, etc. Introducing vulnerabilities (back-doors) in encryption will negatively impact the ability to protect, eh, almost any ICT system. The Internet Society has taken a clear stance on the utility of encryption as a fundamental building block for security and for trust: it should become the norm for Internet communication and governments should not undermine encryption and secure communication tools and technologies.

Private Sector Responsibility and Public Sector Help

It is important that technology companies can assume a primary role and responsibility for the security of their products. They constantly close vulnerabilities in their products so that these cannot be exploited. They constantly reassess the threats and risks that impact the security, and the use of their products. They take action based on those assessments.

When making those assessments they should take into account that devices connected to the Internet are part of the Internet, and vulnerabilities in devices or systems can have an impact anywhere. That does not only apply to end-user devices like PCs that when hacked can be used to perform a denial of service attack on distant services, but also to remote-controlled power breakers that, if compromised, can have large societal impact, see Ukraine.

One of the main arguments in the encryption debate applies more generally: vulnerabilities will eventually be found, exploited and proliferate.

Any suitable vulnerability will be used in exploit kits, i.e. put to use to circumvent security mechanisms and to break and enter ICT systems. The defense against these vulnerabilities is mostly in the hands of the private sector. The public sector helps by greasing the wheels of fixing vulnerabilities through the support of CSIRTs, the facilitation of responsible disclosure, and funding security research. In other words, companies that produce devices and the software that runs on them should be rewarded for seeking out and removing security vulnerabilities, and enlisting the help of security researchers to identify any points of weakness. They should not be required to introduce vulnerabilities no matter how well-intentioned the motive.

Public Debate, not courtrooms

ICT systems are critical to the functioning of society and for the safety of people within that society. Technology companies should be empowered to keep up with state of the art technical security mechanisms to protect those systems and they may be held accountable if they ignore common security practices (the Internet of Things needs serious considerations here). Technical security mechanisms provide the baseline of trust and confidence for an important engine of our societies: ICTs in general and the Internet in particular. And yes, tools in that toolbox also provide hurdles to the job of law enforcement.

On the whole, the Internet Society believes that the balance weighs in favor of the availability of state of the art security mechanisms. They are the strongest enablers for commerce and social interaction, and they help protect human rights. We are of the opinion that governments should use all their available tools and mechanisms to help improve ICT system security, not weaken it.

With that principle as a baseline, there is still a debate to be had around the tools available for law enforcement purposes. There is a tension between the pervasiveness of encryption, the available tools for ‘breaking and entering’, working towards the minimization of vulnerabilities, and preventing crime. This post is not the place to resolve that tension, nor are courtrooms: these debates should be part of a well informed public debate.


Image credit: Lisa Risager on Flickr – CC BY NC ND

Categories
Deploy360 IPv6

Video of Apple WWDC Session About IPv6 and iOS 9 Now Available (And Some Screenshots…)

Want more info about Apple’s new requirement for IPv6 support in iOS 9 applications?  At last week’s WWDC on Friday, June 12, 2015, the session “Your App and Next Generation Networks” covered the topic of IPv6 as well as latency and how to improve the speed of your apps.  The video is now available for viewing (note that on a Mac I was only able to view the video in the Safari browser):

WWDC video about IPv6The IPv6 section was presented by Prabhakar Lakhera, a “Core OS Networking Engineer” at Apple, and runs for about the first 14 minutes of the video.

To give you a view of some of the main points, here are some key screenshots.  First, Prabhakar talked about the need for IPv6 support and pointed out the growth in IPv6 traffic on North American mobile networks (and we’re seeing similar stats at the World IPv6 Launch measurements).

North American mobile networks and IPv6

He then talked about how Apple will use DNS64 and NAT64 to provide connectivity to the IPv4 Internet:

IPv6 using DNS64 and NAT64

He explained that to help in testing, Internet Sharing will now have a “Create NAT64 Network” option:

creating a NAT64 network

and provided a picture of how it all works:

IPv6 testing

He then indicated that 70% of the top 100 free apps had no problem with working over IPv6 and provided these pointers for “What Breaks?”:

What breaks?

It’s interesting to note what he said those points of breakage are:

  • Using IPv4-only storage objects (i.e. storing IPv4 addresses in some form)
  • Using IPv4-only APIs – or using an API in a way that is IPv4-only
  • “Pre-flight checks” (as the app is launching) before connecting and:
    • Checking if the device has an IPv4 address
    • Checking for reachability to 0.0.0.0

These “pre-flight checks” were an interesting item to me as I’d not thought about that mechanism before.  It makes sense for an app developer to check to see if the app can connect out to the Internet before starting to interact with the user.  I’ve had any number of iOS apps do that and warn me when I am not connected to the Internet.  However, only checking for IPv4 would render the app unable to work on an IPv6 network, even if the rest of the code works fine.

Prabhakar then went on to talk about what does work and offered several suggestions:

Apple IPv6 - what works?

Much of this was straightforward:

  • Don’t do a pre-flight check… just try to connect.
  • Use higher-level APIs so you aren’t working with IP addresses

He also encouraged people to read RFC 4038, “Application Aspects of IPv6 Transition”, which is definitely a good read for application developers.

He finished with an interesting addition to iOS 9 and also OS X 10.11.  It has always been possible to use an IP address directly in a URL.  For instance, “http://192.168.10.100/index.html” (which, of course, won’t go anywhere).  But how does an IPv4 “address literal” (as it is called) work in an IPv6-only network?

It turns out that Apple is going to “fix” this by synthesizing an IPv6 address so that the IPv4 literal will still work in an IPv6-only network:

Apple What Works for IPv6

He didn’t provide details of precisely what they are doing for that, but it’s interesting to know about.

There were certainly other parts I didn’t mention… if you are an iOS app developer I’d highly recommend you watch the video.  In fact, I’d also suggest staying on after the IPv6 part is done to watch what Stuart Cheshire has to say about latency and ways to make your app and services work better over congested networks.  Also extremely important!

It’s great to see Apple providing this support and encouraging the movement to IPv6.  We look forward to seeing many more applications work well in IPv6 situations.

If you want to get started learning more about IPv6, please head on over to our Start Here page to find resources to begin!

 

Categories
Deploy360 IPv6

Apple Will Require IPv6 Support For All iOS 9 Apps

Because IPv6 support is so critical to ensuring your applications work across the world for every customer, we are making it an AppStore submission requirement, starting with iOS 9.”  With those words, Sebastien Marineau, Apple’s VP of Core OS, gave a huge boost to IPv6 developer support in Apple’s WWDC Platform State Of The Union (SOTU) address yesterday.

You can watch the Platform SOTU presentation yourself (although you may need the Safari browser to do so). The IPv6 segment begins at 34:16 and Marineau’s statement about the AppStore requirement can be heard at 37:16.

UPDATE: The video of the longer WWDC session about IPv6 is available – and we’ve also captured some of the most important screenshots.

Here, though, is the quick summary.

Why IPv6?

Sebastien Marineau began by talking about IPv6 and why it is important:

Apple IPv6 support

more on IPv6 support

In particular he noted that carriers in several regions of the world are now deploying IPv6-only networks and emphasized the importance of making your application work well for everyone, everywhere.  He reinforced how critical it is to support IPv6:

“If your application doesn’t work properly with IPv6, it will simply not function on those networks, those carriers and for those customers.”

He also explained how Apple has supported IPv6 for over ten years now since early versions of Mac OS X and from iOS 4 onward.

3 Steps For Developers

He went on to explain three steps all developers can take to make sure their applications work over IPv6 networks:

3 steps to make an app work with IPv6

Those steps are:

  • Use the networking frameworks (for example, “NSURLSession”)
  • Avoid use of IPv4-specific APIs
  • Avoid hard-coded IP addresses

Essentially, if app developers are using the higher level APIs and frameworks and aren’t hacking around at the IP layer, their apps should probably “just work” on top of either IPv4 or IPv6.

This is an important point – most iOS developers probably do not need to do anything on the development side. Assuming they have followed best practices in coding and are using the iOS networking frameworks, they should be all set.  Some developers, though, may be using lower level APIs that may involve direct usage of IPv4 addresses. Some developers may also be using the user’s IPv4 address as an identifier or for logging or configuration purposes.

But again, most iOS developers probably don’t need to change their code to support IPv6.

Testing Your App Over IPv6

However, Martineau addressed the question of “how do you test your app over IPv6?“, particularly when many app developers may not have access to a native IPv6 Internet connection.  He indicated that in an upcoming release of Mac OS X there will be a new feature to help with this:

IPv6-only personal hotspot

What I understood Martineau to say was that you will be able to set up a “personal WiFi hotspot” on your Mac and check an “IPv6-only” box.  Your iPhone/iPad with your app could then connect to that specific WiFi network to work in an IPv6-only mode.  The Mac would then provide the gateway to the legacy IPv4 Internet so that the app on the IPv6-only network could connect out to services on IPv4 servers.

THIS IS HUGE! One of the struggles many application developers have had is to easily create an “IPv6-only” network in which to test systems.  Even those of us who are IPv6 advocates/enthusiasts have struggled with making this work well.  It typically involves bringing up a second access point (which you are effectively doing with this new configuration) and then turning off all IPv4 services on that access point, which some access points make difficult to do.

Whenever this feature rolls out in Mac OS X, it will greatly help all of us who are working on apps and systems and want to test them in an IPv6-only environment.

An Important Step

Now, to be clear, most iOS app developers probably won’t have to do all that much to support IPv6.  If they are already using the higher level APIs and networking frameworks they should be all set.  The exact mechanisms of IP address handling are not a concern of theirs.  However, some app developers will have to make some changes, particularly if they are directly using IPv4 addresses as any kind of identifier or in logging.

More importantly, the requirement for AppStore submission will require app developers to test their applications with IPv6 networks, and that alone will suddenly cause the millions of iOS app developers out there to have to learn at least something about IPv6 (if nothing else, the fact that it exists).

Most significantly, though, this step by Apple means that all the iOS apps that run on iOS 9 will work well over the IPv6-only networks that are starting to be deployed.  Even in dual-stack (IPv6/IPv4) networks, this should mean that iOS 9 apps will work better in those environments when, for instance, IPv6 may be faster. (More needs to be understood here about the specifics of the IPv6 support.)

And… this also will help take away the argument used by some network operators who are still not moving ahead with IPv6 that “why should we deploy IPv6 when apps don’t support it?”

Apple’s answer is that, as of iOS 9, all iPhone/iPad apps will support IPv6!

Kudos to Apple for taking these steps, creating this new AppStore submission requirement, and also providing what sounds like a new and easy way to create IPv6-only networks!

We’re looking forward to iOS users being able to use ALL their favorite applications on an IPv6-only network!


UPDATE #1:  Discussions on this post can be found at:

Other articles related to this topic:

UPDATE #2: By way of a tweet I have learned that there is a session at WWDC on Friday, June 12, 2015, about “Your App and Next Generation Networks” that will apparently have more info about IPv6 support.

UPDATE #3 – 19 June 2015: The video of this “Your App and Next Generation Networks” session at WWDC is now available – in the post I link to, I include a number of screenshots about the session.


P.S. If you want to get started with IPv6, please visit our Start Here page to find resources tailored for your role or type of organization.  The time to make the move to IPv6 is TODAY!

Also, hat tip to Adam Iredale on Twitter, who first brought this new requirement to my attention, and to Borja Reinares who provided some more information.

Categories
Deploy360 IPv6

Geoff Huston Unravels An IPv6 Bug Involving Apple Mail And Microsoft Exchange

Geoff Huston's blog postGeoff Huston at APNIC Labs published today a fascinating and very well-documented exploration of why he was having occasional seemingly random problems sending email from his Apple Mail program via APNIC’s Microsoft Exchange Server.

It’s such a good read that I’ll not spoil the story, other than to say it is a good example of the kinds of things application developers need to be thinking about with regard to how they work with IPv6 addresses!

Thanks to Geoff and his colleagues for publishing such a thorough write-up from which we all can learn.

Categories
IPv6

Geoff Huston Unravels An IPv6 Bug Involving Apple Mail And Microsoft Exchange

Geoff Huston's blog postGeoff Huston at APNIC Labs published today a fascinating and very well-documented exploration of why he was having occasional seemingly random problems sending email from his Apple Mail program via APNIC’s Microsoft Exchange Server.

It’s such a good read that I’ll not spoil the story, other than to say it is a good example of the kinds of things application developers need to be thinking about with regard to how they work with IPv6 addresses!

Thanks to Geoff and his colleagues for publishing such a thorough write-up from which we all can learn.

Categories
Deploy360 IPv6

World IPv6 Launch – Should Apple iPad/iPhone/Mac Owners Worry?

The quick answer is “No, IPv6 should ‘just work’,” but the longer answer is more nuanced, as Iljitsch van Beijnum outlines in his excellent piece at Ars Technica, “The future is forever: the state of IPv6 in the Apple world.” In the very detailed piece, van Beijnum covers:

  • the basics of IPv6 support in Apple devices
  • the use of “happy eyeballs” to deal with IPv4/IPv6 transition issues, and some of the issues that can cause
  • privacy addresses in IPv6
  • DHCPv6
  • IPv6 in iOS devices
  • IPv6 in the Airport Extreme base station
  • Firewall issues
  • Airport Utility 6.0 and the missing IPv6 piece

There is also a lengthy stream of comments (81 at the time of this post) that make for interesting reading as well.

The article is an excellent writeup about the status of IPv6 in Apple devices and it would be great to see such articles published for other operating systems and device ecosystems. (If you know of such articles, please feel free to leave links as comments.) Meanwhile, Apple owners should be glad to know that overall they are in very good shape for the impending transition happening with World IPv6 Launch in just over 12 days!

 

Categories
IPv6

World IPv6 Launch – Should Apple iPad/iPhone/Mac Owners Worry?

The quick answer is “No, IPv6 should ‘just work’,” but the longer answer is more nuanced, as Iljitsch van Beijnum outlines in his excellent piece at Ars Technica, “The future is forever: the state of IPv6 in the Apple world.” In the very detailed piece, van Beijnum covers:

  • the basics of IPv6 support in Apple devices
  • the use of “happy eyeballs” to deal with IPv4/IPv6 transition issues, and some of the issues that can cause
  • privacy addresses in IPv6
  • DHCPv6
  • IPv6 in iOS devices
  • IPv6 in the Airport Extreme base station
  • Firewall issues
  • Airport Utility 6.0 and the missing IPv6 piece

There is also a lengthy stream of comments (81 at the time of this post) that make for interesting reading as well.

The article is an excellent writeup about the status of IPv6 in Apple devices and it would be great to see such articles published for other operating systems and device ecosystems. (If you know of such articles, please feel free to leave links as comments.) Meanwhile, Apple owners should be glad to know that overall they are in very good shape for the impending transition happening with World IPv6 Launch in just over 12 days!