Apple pushes HTTPS for 3rd-party apps, will they take their own advice?(bgentry.io)
bgentry.io
Apple pushes HTTPS for 3rd-party apps, will they take their own advice?
https://bgentry.io/blog/2015/06/11/apple-app-transport-security-https
7 comments
What's the deal with iCloud Photos and privacy anyway? I've heard talk of "encrypted at rest" but what does this mean in practice? If someone gets root on Apple's servers, can they see my photos, or only if I'm logged in, or what?
It means that unencrypted data is never written to disk. In the case of S3 it means that if someone gains access to your S3 buckets the data is encrypted.
Of course if you have root-level access to Apple's servers that read S3 you could find the decryption key, though that might not be an easy task.
Of course if you have root-level access to Apple's servers that read S3 you could find the decryption key, though that might not be an easy task.
Not necessarily. The encryption key could be stored in your iCloud keychain, or derived from your login credentials and/or an account-specific identifier stored on your devices. That would prevent anyone from decrypting your data even with root on their servers unless they managed to capture the decryption key out of memory.
Right. In principle, it's possible. Apple maintains it can't read your iMessages, for example. And are there any operations that happen on your photos that have to happen in the cloud? Thumbnail generation/optimisation can happen during upload.
However, since iCloud Photos has a web interface, I imagine they're not doing this.
However, since iCloud Photos has a web interface, I imagine they're not doing this.
It is mostly a protection in cases where an attacker gains physical access to a system (or dumpster dives hard drives). If they are holding on the the encryption key for you then they can obviously decrypt them. I wouldn't consider it safe for anything important.
I've also seen iMessage talk to services hosted on Azure at various points.
They pretty much use everything. Apple was also an early investor in Akamai, and I believe Akamai is still used to transfer iOS and OS X updates.
Factoring keys?
What's the status with the US crypto export paperwork that Apple apparently requires for all crypto-enabled apps, even if they just use iOS builtin URL classes with https urls?
I know first-hand of several non-US apps where https was dropped just because of the opaque and vague requirements. In fact it seems strange to require non-US developers, who purchased an iOS developer program account from a non-US Apple company, to register with US government for "export permission" when all they want to do is publish their app on a non-US app store.
I know first-hand of several non-US apps where https was dropped just because of the opaque and vague requirements. In fact it seems strange to require non-US developers, who purchased an iOS developer program account from a non-US Apple company, to register with US government for "export permission" when all they want to do is publish their app on a non-US app store.
It is still a question Apple asks when you submit your app. It's up to the developer to figure out if they need an encryption registration number or not. The SNAP-R process takes about 3 days and can be done entirely online.
FWIW just a couple weeks ago we got through the whole SNAP-R process a lot faster, in about 2 hours.
It was a strange experience though. It felt like if anything Apple was trying to dissuade us from using encryption by presenting this vague legal hoop with very minimal guidance or concrete examples on what to do.
The few other iOS devs I asked didn't remember much about it, the impression I got is that everyone not working for a big company with a legal or compliance team pretty much just checks "No" whether or not they're using https. Some people likely don't even realize using https counts as encryption, it wasn't explicitly called out anywhere on the form (though it does say something about "even if the encryption is built in to libraries provided by Apple", but of course no list of which libraries might include encryption).
It feels odd and a bit lazy that Apple hasn't made this process any easier, when they clearly think a lot about encryption if they're going so far as to start requiring it. Maybe the legal requirements force them to keep the explanation generic and not do anything to improve the user experience around it.
It was a strange experience though. It felt like if anything Apple was trying to dissuade us from using encryption by presenting this vague legal hoop with very minimal guidance or concrete examples on what to do.
The few other iOS devs I asked didn't remember much about it, the impression I got is that everyone not working for a big company with a legal or compliance team pretty much just checks "No" whether or not they're using https. Some people likely don't even realize using https counts as encryption, it wasn't explicitly called out anywhere on the form (though it does say something about "even if the encryption is built in to libraries provided by Apple", but of course no list of which libraries might include encryption).
It feels odd and a bit lazy that Apple hasn't made this process any easier, when they clearly think a lot about encryption if they're going so far as to start requiring it. Maybe the legal requirements force them to keep the explanation generic and not do anything to improve the user experience around it.
> The SNAP-R process takes about 3 days and can be done entirely online.
True, but last time I looked at it (late 2012) the legalese was intimidating enough that I didn't feel comfortable attempting it without consulting a lawyer. Since the app was just a personal side project, paying for a lawyer wasn't an option and I chose to restrict my app to sale in the US and Canada only. (Which doesn't require any government filing at all.)
All because I wanted to access a backend service over HTTPS. It's mind-boggling that my app can be called "encryption software" because it calls a shared library built into the operating system.
True, but last time I looked at it (late 2012) the legalese was intimidating enough that I didn't feel comfortable attempting it without consulting a lawyer. Since the app was just a personal side project, paying for a lawyer wasn't an option and I chose to restrict my app to sale in the US and Canada only. (Which doesn't require any government filing at all.)
All because I wanted to access a backend service over HTTPS. It's mind-boggling that my app can be called "encryption software" because it calls a shared library built into the operating system.
It doesn't? That must be the reason why so many trivial apps aren't available world-wide. I've always wondered why a publisher wouldn't just click the "worldwide" checkbox.
French iOS users must be missing out even more. Looks like Apple requires extra paperwork for crypto exported to France specifically.
French iOS users must be missing out even more. Looks like Apple requires extra paperwork for crypto exported to France specifically.
For niche one-off apps, like a conference event schedule/program guide, which doesn't process anything particularly sensitive, 3 days with unclear legal paperwork and waiting = https becomes a dealbreaker.
I've spent quite a bit of time reviewing the current regulations and talking on the phone with BIS in the past month about encryption export as part of a contract, it can be complicated or quite simple, depending entirely on things like:
Is it infosec software, or a game/kitchen recipe app?
Is it using "standardized" algorithms? Can they or the key sizes be changed by the end user?
Can the encryption functionality be easily repurposed?
Binaries or source code?
Which destination country(s)?
Who is the intended end user (government vs private entities)?
As there can be significant civil and even criminal penalties for exporting an item without complying with the regulations, the best thing to do in all cases is to call BIS[1] and ask to speak with an export counselor, specifically ask about encryption and you'll get routed to someone who knows the regulations and can tell you exactly what your specific software will require to comply.
> What's the status with the US crypto export paperwork that Apple apparently requires for all crypto-enabled apps, even if they just use iOS builtin URL classes with https urls?
Apple (last time I checked) directs developers to obtain an Encryption Registration Number at minimum, but there can be additional "classification" and reporting requirements depending on the factors I listed above.
> In fact it seems strange to require non-US developers, who purchased an iOS developer program account from a non-US Apple company, to register with US government for "export" when all they want to do is publish their app on a non-US app store.
An export counselor could give a definitive answer but this is likely because the encryption they're using in iOS/OS X is still considered a U.S. controlled item for export purposes, regardless of where they are or where the software using it ends up being sold. That software may end up being considered a U.S. controlled item itself.
I've been told by BIS that re-exporting a U.S. controlled item from a foreign country without complying with U.S. export regulations can come back to bite you down the road, among other things they can completely deny a foreign entity the ability to export or import things to/from the U.S. if they decide export regs have been ignored.
[1] https://www.bis.doc.gov/index.php/about-bis/contact-bis
Is it infosec software, or a game/kitchen recipe app?
Is it using "standardized" algorithms? Can they or the key sizes be changed by the end user?
Can the encryption functionality be easily repurposed?
Binaries or source code?
Which destination country(s)?
Who is the intended end user (government vs private entities)?
As there can be significant civil and even criminal penalties for exporting an item without complying with the regulations, the best thing to do in all cases is to call BIS[1] and ask to speak with an export counselor, specifically ask about encryption and you'll get routed to someone who knows the regulations and can tell you exactly what your specific software will require to comply.
> What's the status with the US crypto export paperwork that Apple apparently requires for all crypto-enabled apps, even if they just use iOS builtin URL classes with https urls?
Apple (last time I checked) directs developers to obtain an Encryption Registration Number at minimum, but there can be additional "classification" and reporting requirements depending on the factors I listed above.
> In fact it seems strange to require non-US developers, who purchased an iOS developer program account from a non-US Apple company, to register with US government for "export" when all they want to do is publish their app on a non-US app store.
An export counselor could give a definitive answer but this is likely because the encryption they're using in iOS/OS X is still considered a U.S. controlled item for export purposes, regardless of where they are or where the software using it ends up being sold. That software may end up being considered a U.S. controlled item itself.
I've been told by BIS that re-exporting a U.S. controlled item from a foreign country without complying with U.S. export regulations can come back to bite you down the road, among other things they can completely deny a foreign entity the ability to export or import things to/from the U.S. if they decide export regs have been ignored.
[1] https://www.bis.doc.gov/index.php/about-bis/contact-bis
It isn't really mentioned, but another reason why using HTTP is unfortunate is due to capturing paywall endpoints that are found in locations such as planes, hotels, etc. If you have software installed to monitor/whitelist all outbound connections, it is extremely frustrating to see your OS services attempting to talk to GoGo's server or some hotel WiFi man-in-the-middle prior to you authenticating and bringing up net access. Fairmont Hotels was actively inserting DIVs into unencrypted sites. Why would I want actors like this to receive any of my traffic? You have to trust Apple at some point, but it would still reassure the public if they pinned certs and you could visibly see the OS only talking to their servers.
I've setup ad-hoc vpn or ssh tunnels when I've had to deal with cases like this... though lately my biggest problem is my carrier (or the mvno). I've been getting <0.3mbps when connected hspa+ with full bars (which used to be close to 10mbps)... I'm not throttled, I only use about 0.3gb/month of the > 5gb before throttling for my account level.
Fortunately, I usually only use trusted wifi at work/home for the most part.
Fortunately, I usually only use trusted wifi at work/home for the most part.
If the content is already encrypted & signed (like imessage & app store content) there is little to be gained by using TLS and a performance cost particularly in latency on unreliable connections (mobile, packet loss, etc).
Did you take a look at the data that's being sent? Are photos encrypted and signed in transport like Apple claims?
Did you take a look at the data that's being sent? Are photos encrypted and signed in transport like Apple claims?
No, I did not take a look at the data being sent. I'm sure that in most of the cases I cited, the HTTP payload is encrypted or at least signed. At the very least, using plain HTTP to communicate with S3 will leak some additional metadata contained in HTTP headers. That may or may not be sensitive or privacy-compromising metadata, but it is metadata that does not need to be leaked.
Without knowing what data is being requested here, I'm not sure there's any issue here.
Perhaps Photos is retrieving data which has an embedded signature, making SSL irrelevant? Or the data isn't security-critical anyway (e.g, it's checking for a news splashscreen or something). The point is, simply using unencrypted communications doesn't necessarily mean the application is insecure.
Perhaps Photos is retrieving data which has an embedded signature, making SSL irrelevant? Or the data isn't security-critical anyway (e.g, it's checking for a news splashscreen or something). The point is, simply using unencrypted communications doesn't necessarily mean the application is insecure.
No, lack of HTTPS does not guarantee a lack of security. That applies to Apple just as it does to the 3rd party devs they're pushing to use HTTPS.
You can actually upload client-side encrypted data to S3 buckets. With one-time upload tokens. So what they are doing may be perfectly fine.
Hard to tell without seeing the complete request.
Hard to tell without seeing the complete request.
1. http://readwrite.com/2014/08/26/apple-icloud-amazon-web-serv...