

Apple pushes HTTPS for 3rd-party apps, will they take their own advice? - bgentry
https://bgentry.io/blog/2015/06/11/apple-app-transport-security-https

======
colinbartlett
The shocking thing for me is that Apple is using Amazon S3 to store iCloud
photos. Apparently this is not news[1], but it's news to me. What are all
those huge green data centers for if not for mountains of iCloud content?

1\. [http://readwrite.com/2014/08/26/apple-icloud-amazon-web-
serv...](http://readwrite.com/2014/08/26/apple-icloud-amazon-web-services-
hosting)

~~~
Osmium
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?

~~~
sitharus
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.

~~~
danudey
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.

~~~
Osmium
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.

------
0x0
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.

~~~
mapmap
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.

~~~
profmonocle
> 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.

~~~
0x0
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.

------
apaprocki
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.

~~~
tracker1
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.

------
larrysalibra
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?

~~~
bgentry
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.

------
duskwuff
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.

~~~
bgentry
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.

------
st3fan
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.

