19 ms·

Apple Delays iOS SSL Requirement Indefinitely

160 points by mark-ruwt 10y ago

UnoriginalGuy 10y ago
The title at the time of posting reads: "Apple Delays iOS SSL Requirement Indefinitely." "Indefinitely" while technically accurate also implies "unlimited period of time." The article says there will be a deadline, it just hasn't been determined as of yet. A better title may be "Apple Delays iOS TLS App Requirement." Just simply chop off the word "indefinitely." And throw in App to differentiate it from a e.g. Safari TLS requirement. Also TLS instead of SSL.
- mark-ruwt 10y ago
  Indefinitely means "for an unlimited or unspecified period of time". http://www.dictionary.com/browse/indefinitely http://www.dictionary.com/browse/indefinitely
  - UnoriginalGuy 10y ago
    I know. Which is why my post reads: > "Indefinitely" while technically accurate also implies "unlimited period of time." It has two meanings. But is more often used to mean unlimited period of time.
    - cooper12 10y ago
      Yep I read the title and assumed that the first meaning was meant.
  - deleted 10y ago
    [deleted]
- pvg 10y ago
  You should email this stuff to the mods since they don't read every post. It's definitely a confusing title.
- deleted 10y ago
  [deleted]
orasis 10y ago
I think at least NSURLSession is forcing HTTPS currently.
- orbitur 10y ago
  You can disable that by adding a key to your Info.plist. They mean at the App Store submission point. In January, they were going to start rejecting apps that didn't provide a justification for completely disabling ATS.
orbitur 10y ago
I don't get why they're delaying this. My understanding was that fully disabling ATS would require a justification. That makes sense. It's annoying to have to audit your apps and enumerate the endpoints, but as long as Apple didn't require justification for explicit domain exceptions, everything should've been fine.
- deleted 10y ago
  [deleted]
- eugeniub 10y ago
  That's not quite right. You will still have to justify every domain exception. > By the end of 2016, when your apps communicate with your own server back ends, they must do so using a secure TLS channel using TLS 1.2, unless the data being communicated is bulk data such as media streaming and data that’s already encrypted. https://nakedsecurity.sophos.com/2016/06/17/apple-ios-to-require-https-for-apps-by-january/ https://nakedsecurity.sophos.com/2016/06/17/apple-ios-to-req...
- gilgoomesh 10y ago
  > but as long as Apple didn't require justification for explicit domain exceptions The previous plan was they they were going to require justification for every domain exception. Further, they were going to require justification if you were already using HTTP Live Streaming... Apple's own protocol which is written to use AES encrypted segments over plain HTTP. They were going to require justification for peer connections that have to jump through hoops to get URLSession recognize their self-signed certificates. This one in particular is still affecting one of my apps. It's not always possible to force peer certificates to be accepted, making HTTPS between peers very difficult (seemingly impossible) at times. I'm not saying that these things can't be done but I think Apple underestimated the number of systems affected and the justifications and reasons involved. HTTPS is fundamentally not "everywhere", despite its prevalence in larger systems.
  - valarauca1 10y ago
    You really shouldn't do HTTPS if you can't complete the chain of trust with a peer. If one is doing some multi-cast multi-tenant swarm stuff... why is the data private? It seems like a lot of people have access.
omarforgotpwd 10y ago
They probably just don't want to break a bunch of applications that haven't updated yet. It would be nice if they could make it a configurable option for those of us who don't use / care to use apps that are still not using HTTPS. "Allow Secure Connections Only" checkbox in Settings or something.
- sigjuice 10y ago
  IMHO, it is not Apple's style to make such things configurable.
- wilg 10y ago
  Having a configurable option to disable a security setting is a pretty bad idea. Users who don't know anything about security will just disable it forever the first time an app tells them to.
  - 0xFFC 10y ago
    I think you missed the idea, It could be temporary thing for a while, after a year or two and with continues beforehand notification, apple could disable non-secure connection apps definitely. kind of like transition period.
    - dogma1138 10y ago
      No there shouldn't be a configurable setting; giving users a choice just creates problems; giving developers a way out just delays implementation. As long as there is a way for an App to make non-SSL connection you'll have to run a non-SSL enabled endpoint; which in effect can put users at risk even if they haven't configured their own devices/apps to use it.
  - JoshTriplett 10y ago
    > Having a configurable option to disable a security setting is a pretty bad idea. I think the proposal was to have a configurable option to enable an extra security lockdown, which would remain disabled by default.
LeicaLatte 10y ago
I expect the likes of Facebook, Microsoft to already be ATS-ready. But it has been my experience that Unreal Engine 4 and Unity are not. Its probably the big game makers of the App Store that are influencing this delay.
- Ambroos 10y ago
  Try media companies. We have been working to make our television companion apps ATS-compliant. All our advertising / analytics / streaming endpoints had to be HTTPS. We ended up with a list of dozens of domains from over 10 external companies (mostly related to video ads / streams) that still had to be made available over HTTPS, or we'd have to get exemptions for those domains. We're still going on with our efforts to make everything go over HTTPS always, but this does take the pressure off a little. We were really fearing not being able to submit updates in early 2017 because of ATS.
  - orbitur 10y ago
    We have similar clients. They insist every app must have at least 5 different analytics/ad providers and god knows what else. I was honestly kinda looking forward to January because it would force them to re-evaluate some of the shittier providers so they could get app updates out.
atesti 10y ago
How would ATS affect apps which don't just talk to one server of the developer of that app? What if an app should talk directly over wifi to a device in your local home network via HTTP? Or to a system that each company who buys it hosts on their own and in the app the customer has to supply that hostname or IP in order to connect? Would ATS have enforced that there could only be a few centralized cloud servers? And can I simply bypass ATS by linking in curl+openssl? Are iOS apps even allowed to open raw TCP sockets?
- comex 10y ago
  > How would ATS affect apps which don't just talk to one server of the developer of that app? What if an app should talk directly over wifi to a device in your local home network via HTTP? iOS 10 adds the key NSAllowsLocalNetworking which disables ATS for "connections to unqualified domains and to .local domains". So this can continue to work. However, treating local networks as secure isn't generally a good design! If the home network has an open Wi-Fi hotspot, or a WPA hotspot with WPS PIN enabled or where the attacker knows or can bruteforce the password (and in many other cases), it is possible to sniff other users' traffic. Instead of using an unencrypted connection, whether HTTP or otherwise, you should design the initial pairing process between the app and the device to set up encryption keys. For HTTPS this can be in the form of having the device generate a self-signed certificate and send it to the app to use as a custom root. You need some sort of pairing or setup process anyway for the device to know how to connect to the user's network, so you might as well do security properly. > Or to a system that each company who buys it hosts on their own and in the app the customer has to supply that hostname or IP in order to connect? In that case you should probably just require the companies to have a domain and a certificate for it; build in Let's Encrypt support if you want. > And can I simply bypass ATS by linking in curl+openssl? From a technical perspective, yes, though I can't say whether Apple would reject an app because of it. > Are iOS apps even allowed to open raw TCP sockets? Yes.
cyb3rl0l 10y ago
What was supposed to happen on January 1st: https://datatheorem.github.io/ios/ssl/2016/08/14/ats-enforced-2017/ https://datatheorem.github.io/ios/ssl/2016/08/14/ats-enforce... . "The overall approach the App Store review team will take when it comes to ATS exemptions was summed up on the Apple developer forums: “The goal here is to flush out those folks who, when ATS was first released, simply turned it off globally and moved on. That will no longer be allowed.” Hence, for a given App going through the App Store review process: * An easy policy to justify is to have NSAllowsArbitraryLoads disabled and a list of domain-specific exemptions for third-party domains the App connects to. * A policy that will be harder to justify is to have NSAllowsArbitraryLoads enabled and a list of domain-specific “un-exemptions” for the domains you control. * Lastly, a policy that will definitely trigger a rejection, as stated by Apple, is to have NSAllowsArbitraryLoads enabled with no additional ATS settings. " Since most Apps are not compliant yet, the App Store review team would have had to review every justification for every App and make a decision on whether to allow the App on the Store or not.
bgentry 10y ago
Apple's own services make extensive use of plaintext HTTP. Even if they're only doing so in ways that are safe (due to other application layer encryption mechanisms like in iMessage) it's hypocritical for them to enforce a requirement on 3rd parties that they themselves cannot meet.
- azinman2 10y ago
  Can you give an example of this? I've been using charles proxy for various tasks a bunch on my iPhone, and so far it seems that all the calls to Apple that I've noticed are HTTPS.
  - mahyarm 10y ago
    Use little snitch on your mac OS computer, you'll see all sorts of port 80 connections to things like mzstatic.com and so on.
    - orbitur 10y ago
      Oh. That's the platform they don't really care about.
  - bgentry 10y ago
    Here's a partial list from my Little Snitch config on macOS Sierra: - com.apple.geod.xpc tried to establish a connection to gspe19.ls.apple.com on port 80 - App Store / softwareupdated uses port 80 to download updates from swcdn.apple.com - helpd uses port 80 to fetch help docs from the web - IMTransferAgent tried to establish a connection to ussjc.ce.apple-dns.net on port 80. This is used by Messages.app when picture messages are received. - iTunes uses port 80 all over the place to fetch content from the mzstatic CDN and others - nsurlsessiond uses port 80 to fetch from apple-dns.net, blobstore.apple.com, icloud-content.com, aaplimg.com - photolibraryd via com.apple.photomoments.xpc tried to establish a connection to gspe21.ls.apple.com on port 80 - Photos Agent tried to establish a connection to s3-w-a.us-west-2.amazonaws.com on port 80 - storeaccountd tried to establish a connection to sandbox.itunes-apple.com.akadns.net on port 80 - storedownloadd tried to establish a connection to osxapps.itunes.apple.com on port 80 - SpotlightNetHelper tried to establish a connection to wu-calculator.apple.com on port 80
lopezmars 10y ago
As usual.. Not surprising at all.
Bino 10y ago
Speaking of Transport Security, last night I got bitten by the removal of OpenSSL headers in Xcode in favor of their own "-framework security" aka Secure Transport.
- X-Istence 10y ago
  Apple has had deprecated on the OpenSSL headers for a couple of releases now...
gnicholas 10y ago
Glad to see this. I'm about to release a new version of my app (a news reader, which makes extensive use of webviews), and I was sweating about this. I don't control any of the news sites that we interface with, and I was surprised to see that most don't support SSL. While we could request exceptions for every single one, this would require updating the app every time we enable a new HTTP site through our back-end. I was not looking forward to this, and I wondered how many others were similarly dreading the transition. On a related note, does anyone know how Firefox, Chrome, or other browsers are handling this? Don't they need to have a universal exception for HTTP, which is not supposed to be allowed under the new rule?
- cyb3rl0l 10y ago
  Apple introduced an ATS exemption specifically designed for the browse-to-any-website-in-a-webview use case. You can also use the Safari ViewController which doesn't enforce ATS (by design). Hence you don't need to list all these third party domains in your Info.plist.
  - gnicholas 10y ago
    Unfortunately, the Safari ViewController doesn't do everything that the old UIWebView and WKWebView did. I think in our case we needed to be able to increment the cache size (to be compatible with Kindle Cloud reader), and this was only available on UIWebView. I could be mistaken here, and regardless I hope the Safari ViewController is updated to support this feature. Forgive me if I've misused terminology here—I'm the non-technical founder—so my understanding of why we couldn't use the Safari WebView (which I assume is the same or closely related to what you referenced) is a bit fuzzy. All I know for sure was that our dev team was not looking forward to pleading for ATS exceptions.
  - untog 10y ago
    The Safari view controller is a very different beast to UI/WKWebView, though - if you want to do any kind of integration between the webview and app you're pretty much locked out.
deleted 10y ago
[deleted]
coldcode 10y ago
The apps at my F50 employer are in no way compatible with these requirements, and getting all the VPs to care about this is unlikely to ever reach even the minimal level of concern. Of course this is sad and stupid and shortsighted but unless Apple enforces it and our apps were refused updates nothing will ever change.
dep_b 10y ago
It was always a nice way to force my customers to implement HTTPS, the threat of Apple rejecting or removing the app. It's pretty easy to implement and inexpensive so why people still don't do it is a complete mystery to me.
- 0x0 10y ago
  I think you also have to register with some US government body to obtain crypto export licenses yearly. Even if the app just uses the iOS https connection classes!
  - stepanhruda 10y ago
    No you don't.
    - deleted 10y ago
      [deleted]
    - 0x0 10y ago
      It used to be like that, but it seems like this was changed in the last month?! http://stackoverflow.com/a/40919650 http://stackoverflow.com/a/40919650 For all the downvoters on my parent post: This blog from last year said something else: https://pupeno.com/2015/12/15/legally-submit-app-apples-app-store-uses-encryption-obtain-ern/ https://pupeno.com/2015/12/15/legally-submit-app-apples-app-... Edit: Downvote me all you want, but the OP asked why people just didn't implement HTTPS and I have first hand knowledge of several apps that chose to not implement HTTPS because the legal work required around crypto export licenses was too much to be worth it.
      - stepanhruda 10y ago
        It was always exempt because you weren't shipping your own crypto implementation. Apple has to comply when shipping iOS. Those apps were not shipping HTTPS for a non-reason. This recent change only made the wording clearer in iTunes Connect.
xgbi 10y ago
This does not sound like the Apple I know about. I mean, these guys forced every app to be able to handle IPV6-only network operations last year. And this was after making all apps switch to 64 bits a bit earlier. Why did they back up off SSL? I feel like this is kind of a turning point, where Apple, instead of driving the market with innovative APIs and having a vision, now tries to compromise and removes innovative features to keep its immense app market happy, and oblige for it. What a let down, especially after a very nice 2016 year, where they stood against the FBI and published their open letter about privacy of their customers.
- rgsh22 10y ago
  > Why did they back up off SSL? Go try and buy something on https://apple.com https://apple.com - you will once you go to view your cart you will be redirected to plain vanilla HTTP. There is no way around this. If they can't get their own SSL support in order...
  - rawrmaan 10y ago
    Why is there no way around this? This is surprising to me and I'm super curious.
    - sdegutis 10y ago
      If I had to give them the benefit of the doubt, I'd guess that they feel that SSL has failed at fulfilling its intended purpose, and that they're working on a "superior" alternative which they plan to use for themselves and force all developers for their platforms to also use, in an attempt to encourage it to spread and supersede SSL.
    - brazzledazzle 10y ago
      The exchange of payment or authentication information is undoubtedly done over TLS so it's probably just not a priority. That said there seems to be some obvious security issues with it since a bad actor could, as far as I know, inject malicious javascript in the vanilla http page to do all kinds of fun stuff.
droningparrot 10y ago
In other news, rumours report that the next iMac will reintroduce the floppy drive
ejcx 10y ago
Friend of mine works at a really REALLY big bank. Works on their iOS app and their SSL cert is long expired. The iOS client does certificate pinning, so it isn't a huge security concern (although revocation would be a nightmare), but it does not surprise me that people are afraid of supporting TLS only for their apps.
- willstrafach 10y ago
  That is fine though. ATS just ensures you are using TLS v1.2 and such, but doesn't enforce expiration / CRL / trusted roots / etc. That would be done in app, usually using default built-in frameworks but sometimes with custom logic to do things like certificate pinning.

160 points by mark-ruwt 10y ago

The title at the time of posting reads: "Apple Delays iOS SSL Requirement Indefinitely." "Indefinitely" while technically accurate also implies "unlimited period of time." The article says there will be a deadline, it just hasn't been determined as of yet. A better title may be "Apple Delays iOS TLS App Requirement." Just simply chop off the word "indefinitely." And throw in App to differentiate it from a e.g. Safari TLS requirement. Also TLS instead of SSL.

mark-ruwt 10y ago
Indefinitely means "for an unlimited or unspecified period of time". http://www.dictionary.com/browse/indefinitely http://www.dictionary.com/browse/indefinitely
- UnoriginalGuy 10y ago
  I know. Which is why my post reads: > "Indefinitely" while technically accurate also implies "unlimited period of time." It has two meanings. But is more often used to mean unlimited period of time.
  - cooper12 10y ago
    Yep I read the title and assumed that the first meaning was meant.
- deleted 10y ago
  [deleted]
pvg 10y ago
You should email this stuff to the mods since they don't read every post. It's definitely a confusing title.
deleted 10y ago
[deleted]

orasis 10y ago

I think at least NSURLSession is forcing HTTPS currently.

orbitur 10y ago
You can disable that by adding a key to your Info.plist. They mean at the App Store submission point. In January, they were going to start rejecting apps that didn't provide a justification for completely disabling ATS.

orbitur 10y ago

I don't get why they're delaying this. My understanding was that fully disabling ATS would require a justification. That makes sense. It's annoying to have to audit your apps and enumerate the endpoints, but as long as Apple didn't require justification for explicit domain exceptions, everything should've been fine.

deleted 10y ago
[deleted]
eugeniub 10y ago
That's not quite right. You will still have to justify every domain exception. > By the end of 2016, when your apps communicate with your own server back ends, they must do so using a secure TLS channel using TLS 1.2, unless the data being communicated is bulk data such as media streaming and data that’s already encrypted. https://nakedsecurity.sophos.com/2016/06/17/apple-ios-to-require-https-for-apps-by-january/ https://nakedsecurity.sophos.com/2016/06/17/apple-ios-to-req...
gilgoomesh 10y ago
> but as long as Apple didn't require justification for explicit domain exceptions The previous plan was they they were going to require justification for every domain exception. Further, they were going to require justification if you were already using HTTP Live Streaming... Apple's own protocol which is written to use AES encrypted segments over plain HTTP. They were going to require justification for peer connections that have to jump through hoops to get URLSession recognize their self-signed certificates. This one in particular is still affecting one of my apps. It's not always possible to force peer certificates to be accepted, making HTTPS between peers very difficult (seemingly impossible) at times. I'm not saying that these things can't be done but I think Apple underestimated the number of systems affected and the justifications and reasons involved. HTTPS is fundamentally not "everywhere", despite its prevalence in larger systems.
- valarauca1 10y ago
  You really shouldn't do HTTPS if you can't complete the chain of trust with a peer. If one is doing some multi-cast multi-tenant swarm stuff... why is the data private? It seems like a lot of people have access.

omarforgotpwd 10y ago

They probably just don't want to break a bunch of applications that haven't updated yet. It would be nice if they could make it a configurable option for those of us who don't use / care to use apps that are still not using HTTPS. "Allow Secure Connections Only" checkbox in Settings or something.

sigjuice 10y ago
IMHO, it is not Apple's style to make such things configurable.
wilg 10y ago
Having a configurable option to disable a security setting is a pretty bad idea. Users who don't know anything about security will just disable it forever the first time an app tells them to.
- 0xFFC 10y ago
  I think you missed the idea, It could be temporary thing for a while, after a year or two and with continues beforehand notification, apple could disable non-secure connection apps definitely. kind of like transition period.
  - dogma1138 10y ago
    No there shouldn't be a configurable setting; giving users a choice just creates problems; giving developers a way out just delays implementation. As long as there is a way for an App to make non-SSL connection you'll have to run a non-SSL enabled endpoint; which in effect can put users at risk even if they haven't configured their own devices/apps to use it.
- JoshTriplett 10y ago
  > Having a configurable option to disable a security setting is a pretty bad idea. I think the proposal was to have a configurable option to enable an extra security lockdown, which would remain disabled by default.

LeicaLatte 10y ago

I expect the likes of Facebook, Microsoft to already be ATS-ready. But it has been my experience that Unreal Engine 4 and Unity are not. Its probably the big game makers of the App Store that are influencing this delay.

Ambroos 10y ago
Try media companies. We have been working to make our television companion apps ATS-compliant. All our advertising / analytics / streaming endpoints had to be HTTPS. We ended up with a list of dozens of domains from over 10 external companies (mostly related to video ads / streams) that still had to be made available over HTTPS, or we'd have to get exemptions for those domains. We're still going on with our efforts to make everything go over HTTPS always, but this does take the pressure off a little. We were really fearing not being able to submit updates in early 2017 because of ATS.
- orbitur 10y ago
  We have similar clients. They insist every app must have at least 5 different analytics/ad providers and god knows what else. I was honestly kinda looking forward to January because it would force them to re-evaluate some of the shittier providers so they could get app updates out.

atesti 10y ago

How would ATS affect apps which don't just talk to one server of the developer of that app? What if an app should talk directly over wifi to a device in your local home network via HTTP? Or to a system that each company who buys it hosts on their own and in the app the customer has to supply that hostname or IP in order to connect? Would ATS have enforced that there could only be a few centralized cloud servers? And can I simply bypass ATS by linking in curl+openssl? Are iOS apps even allowed to open raw TCP sockets?

comex 10y ago
> How would ATS affect apps which don't just talk to one server of the developer of that app? What if an app should talk directly over wifi to a device in your local home network via HTTP? iOS 10 adds the key NSAllowsLocalNetworking which disables ATS for "connections to unqualified domains and to .local domains". So this can continue to work. However, treating local networks as secure isn't generally a good design! If the home network has an open Wi-Fi hotspot, or a WPA hotspot with WPS PIN enabled or where the attacker knows or can bruteforce the password (and in many other cases), it is possible to sniff other users' traffic. Instead of using an unencrypted connection, whether HTTP or otherwise, you should design the initial pairing process between the app and the device to set up encryption keys. For HTTPS this can be in the form of having the device generate a self-signed certificate and send it to the app to use as a custom root. You need some sort of pairing or setup process anyway for the device to know how to connect to the user's network, so you might as well do security properly. > Or to a system that each company who buys it hosts on their own and in the app the customer has to supply that hostname or IP in order to connect? In that case you should probably just require the companies to have a domain and a certificate for it; build in Let's Encrypt support if you want. > And can I simply bypass ATS by linking in curl+openssl? From a technical perspective, yes, though I can't say whether Apple would reject an app because of it. > Are iOS apps even allowed to open raw TCP sockets? Yes.

cyb3rl0l 10y ago

What was supposed to happen on January 1st: https://datatheorem.github.io/ios/ssl/2016/08/14/ats-enforced-2017/ https://datatheorem.github.io/ios/ssl/2016/08/14/ats-enforce... . "The overall approach the App Store review team will take when it comes to ATS exemptions was summed up on the Apple developer forums: “The goal here is to flush out those folks who, when ATS was first released, simply turned it off globally and moved on. That will no longer be allowed.” Hence, for a given App going through the App Store review process: * An easy policy to justify is to have NSAllowsArbitraryLoads disabled and a list of domain-specific exemptions for third-party domains the App connects to. * A policy that will be harder to justify is to have NSAllowsArbitraryLoads enabled and a list of domain-specific “un-exemptions” for the domains you control. * Lastly, a policy that will definitely trigger a rejection, as stated by Apple, is to have NSAllowsArbitraryLoads enabled with no additional ATS settings. " Since most Apps are not compliant yet, the App Store review team would have had to review every justification for every App and make a decision on whether to allow the App on the Store or not.

bgentry 10y ago

Apple's own services make extensive use of plaintext HTTP. Even if they're only doing so in ways that are safe (due to other application layer encryption mechanisms like in iMessage) it's hypocritical for them to enforce a requirement on 3rd parties that they themselves cannot meet.

azinman2 10y ago
Can you give an example of this? I've been using charles proxy for various tasks a bunch on my iPhone, and so far it seems that all the calls to Apple that I've noticed are HTTPS.
- mahyarm 10y ago
  Use little snitch on your mac OS computer, you'll see all sorts of port 80 connections to things like mzstatic.com and so on.
  - orbitur 10y ago
    Oh. That's the platform they don't really care about.
- bgentry 10y ago
  Here's a partial list from my Little Snitch config on macOS Sierra: - com.apple.geod.xpc tried to establish a connection to gspe19.ls.apple.com on port 80 - App Store / softwareupdated uses port 80 to download updates from swcdn.apple.com - helpd uses port 80 to fetch help docs from the web - IMTransferAgent tried to establish a connection to ussjc.ce.apple-dns.net on port 80. This is used by Messages.app when picture messages are received. - iTunes uses port 80 all over the place to fetch content from the mzstatic CDN and others - nsurlsessiond uses port 80 to fetch from apple-dns.net, blobstore.apple.com, icloud-content.com, aaplimg.com - photolibraryd via com.apple.photomoments.xpc tried to establish a connection to gspe21.ls.apple.com on port 80 - Photos Agent tried to establish a connection to s3-w-a.us-west-2.amazonaws.com on port 80 - storeaccountd tried to establish a connection to sandbox.itunes-apple.com.akadns.net on port 80 - storedownloadd tried to establish a connection to osxapps.itunes.apple.com on port 80 - SpotlightNetHelper tried to establish a connection to wu-calculator.apple.com on port 80

lopezmars 10y ago

As usual.. Not surprising at all.

Bino 10y ago

Speaking of Transport Security, last night I got bitten by the removal of OpenSSL headers in Xcode in favor of their own "-framework security" aka Secure Transport.

X-Istence 10y ago
Apple has had deprecated on the OpenSSL headers for a couple of releases now...

gnicholas 10y ago

Glad to see this. I'm about to release a new version of my app (a news reader, which makes extensive use of webviews), and I was sweating about this. I don't control any of the news sites that we interface with, and I was surprised to see that most don't support SSL. While we could request exceptions for every single one, this would require updating the app every time we enable a new HTTP site through our back-end. I was not looking forward to this, and I wondered how many others were similarly dreading the transition. On a related note, does anyone know how Firefox, Chrome, or other browsers are handling this? Don't they need to have a universal exception for HTTP, which is not supposed to be allowed under the new rule?

cyb3rl0l 10y ago
Apple introduced an ATS exemption specifically designed for the browse-to-any-website-in-a-webview use case. You can also use the Safari ViewController which doesn't enforce ATS (by design). Hence you don't need to list all these third party domains in your Info.plist.
- gnicholas 10y ago
  Unfortunately, the Safari ViewController doesn't do everything that the old UIWebView and WKWebView did. I think in our case we needed to be able to increment the cache size (to be compatible with Kindle Cloud reader), and this was only available on UIWebView. I could be mistaken here, and regardless I hope the Safari ViewController is updated to support this feature. Forgive me if I've misused terminology here—I'm the non-technical founder—so my understanding of why we couldn't use the Safari WebView (which I assume is the same or closely related to what you referenced) is a bit fuzzy. All I know for sure was that our dev team was not looking forward to pleading for ATS exceptions.
- untog 10y ago
  The Safari view controller is a very different beast to UI/WKWebView, though - if you want to do any kind of integration between the webview and app you're pretty much locked out.

deleted 10y ago

[deleted]

coldcode 10y ago

The apps at my F50 employer are in no way compatible with these requirements, and getting all the VPs to care about this is unlikely to ever reach even the minimal level of concern. Of course this is sad and stupid and shortsighted but unless Apple enforces it and our apps were refused updates nothing will ever change.

dep_b 10y ago

It was always a nice way to force my customers to implement HTTPS, the threat of Apple rejecting or removing the app. It's pretty easy to implement and inexpensive so why people still don't do it is a complete mystery to me.

0x0 10y ago
I think you also have to register with some US government body to obtain crypto export licenses yearly. Even if the app just uses the iOS https connection classes!
- stepanhruda 10y ago
  No you don't.
  - deleted 10y ago
    [deleted]
  - 0x0 10y ago
    It used to be like that, but it seems like this was changed in the last month?! http://stackoverflow.com/a/40919650 http://stackoverflow.com/a/40919650 For all the downvoters on my parent post: This blog from last year said something else: https://pupeno.com/2015/12/15/legally-submit-app-apples-app-store-uses-encryption-obtain-ern/ https://pupeno.com/2015/12/15/legally-submit-app-apples-app-... Edit: Downvote me all you want, but the OP asked why people just didn't implement HTTPS and I have first hand knowledge of several apps that chose to not implement HTTPS because the legal work required around crypto export licenses was too much to be worth it.
    - stepanhruda 10y ago
      It was always exempt because you weren't shipping your own crypto implementation. Apple has to comply when shipping iOS. Those apps were not shipping HTTPS for a non-reason. This recent change only made the wording clearer in iTunes Connect.

xgbi 10y ago

This does not sound like the Apple I know about. I mean, these guys forced every app to be able to handle IPV6-only network operations last year. And this was after making all apps switch to 64 bits a bit earlier. Why did they back up off SSL? I feel like this is kind of a turning point, where Apple, instead of driving the market with innovative APIs and having a vision, now tries to compromise and removes innovative features to keep its immense app market happy, and oblige for it. What a let down, especially after a very nice 2016 year, where they stood against the FBI and published their open letter about privacy of their customers.

rgsh22 10y ago
> Why did they back up off SSL? Go try and buy something on https://apple.com https://apple.com - you will once you go to view your cart you will be redirected to plain vanilla HTTP. There is no way around this. If they can't get their own SSL support in order...
- rawrmaan 10y ago
  Why is there no way around this? This is surprising to me and I'm super curious.
  - sdegutis 10y ago
    If I had to give them the benefit of the doubt, I'd guess that they feel that SSL has failed at fulfilling its intended purpose, and that they're working on a "superior" alternative which they plan to use for themselves and force all developers for their platforms to also use, in an attempt to encourage it to spread and supersede SSL.
  - brazzledazzle 10y ago
    The exchange of payment or authentication information is undoubtedly done over TLS so it's probably just not a priority. That said there seems to be some obvious security issues with it since a bad actor could, as far as I know, inject malicious javascript in the vanilla http page to do all kinds of fun stuff.

droningparrot 10y ago

In other news, rumours report that the next iMac will reintroduce the floppy drive

ejcx 10y ago

Friend of mine works at a really REALLY big bank. Works on their iOS app and their SSL cert is long expired. The iOS client does certificate pinning, so it isn't a huge security concern (although revocation would be a nightmare), but it does not surprise me that people are afraid of supporting TLS only for their apps.

willstrafach 10y ago
That is fine though. ATS just ensures you are using TLS v1.2 and such, but doesn't enforce expiration / CRL / trusted roots / etc. That would be done in app, usually using default built-in frameworks but sometimes with custom logic to do things like certificate pinning.