12

The update in question is the Mavericks combined update which, among other things, claims to fix the recent SSL vulnerability/gaping hole.

This issue really annoyed me, so I decided to procure Apple's PGP key and verify it as best I could. And I snooped my traffic with Wireshark during the downloads. Here are my findings:

  • Getting and verifying Apple's PGP key was a waste of time, because as far as I can tell they don't issue signatures for software updates
  • The update downloader connects over HTTPS to their software download locator domain, which redirects to the actual update on a CDN (in my case apple.vo.llnwd.net)
  • Every single bit of the update package comes over plain old HTTP from the CDN
  • Every single packet of the update is followed by a duplicate ACK (this only happens with the update, all my other downloads are fine, so I don't think it's my infrastructure)
  • Manually downloading the dmg archive from here is HTTP by default. Enforcing HTTPS causes a redirect to the actual (HTTP) file URI, HTTPS is not enabled for this URI.

Apple (presumably responding to criticism of yesteryear) specifically say that updates are delivered over HTTPS except where "complicated proxy set ups" make this impossible. I have tried to download over my vanilla connection and 2 offshore VPN's, and for love nor money can I get an HTTPS link to that file (software update or via website).

My questions are:

  1. In your opinion are they - or someone in between - playing funny buggers?
  2. Is there suspicion to be drawn from all those duplicate ACKs? (I don't know enough about this to even speculate)

I'm suspicious because if I was the NSA/GCHQ and I had a weeks warning to intercept and replace blobs of binary on predictable HTTP endpoints that will auto-execute because code signing on millions of target machines is entirely broken, I'd probably think Christmas had come twice. I don't see any circumstance under which they could pass up such an opportunity if they were capable of it, and from everything I've read they are more than capable such a thing.

Improve this question
8
  • Most actual downloads are done over HTTP, because it's faster and downloads don't really need security. It seems to me that if a hacker really wanted to get that update, he'd just download it himself, not sniff your connection...
    – KnightOfNi
    Feb 27, 2014 at 21:20
  • Code Signing wasn't broken (at least with this bug, nobody can say the NSA/friends don't know about other bugs), so Christmas didn't come twice- at least in this specific situation. In fact, the NSA more than likely have access to at least a couple Root certificates (or at least Intermediates), so this whole SSL thing likely wasn't that exciting for them (except for situations where the certificate was pinned, or the target wasn't trusting the normal CAs).
    – Kitsune
    Feb 28, 2014 at 2:13
  • 2
    @KnightOfNi I wasn't meaning to suggesting an attacker would use my connection to get the download, rather that they could intercept and replace it.
    – CHT
    Mar 3, 2014 at 18:46
  • @Kitsune My mistake, I read somewhere that code signing was affected. I understand what you're saying about root CA's, and I'd be inclined to agree the intelligence community at least have access to the private keys of some, but what happened with Lavabit suggests they don't have them all. Also if I was trying very hard to secure my communications, I would most certainly use a self-signed CA because of the too-much-trust-in-root-CAs problem, as a great many enterprises do.
    – CHT
    Mar 3, 2014 at 18:50
  • 1
    Even if someone isn't messing with it, you still have no straightforward way to verify the software that Apple is sending you doesn't do something you don't want it to.
    – Evan Cordell
    Mar 3, 2014 at 19:35

1 Answer 1

Reset to default
1

(The below is all speculation, I don't know how Apple's updater works internally.)

There are definitely architectures that can perform a secure update over HTTP. Almost all Linux distributions distribute packages in plaintext, and verify them by verifying the hashes (SHA-1, SHA-256, etc.) from the repository metadata. The repository metadata, in turn, is signed with a GPG key that your host verifies, and was installed with your original installation media. (If your original install media was backdoored, all bets are off forever.)

So what does this have to do with your Apple update? Apple could be using a similar scheme -- send a hash over HTTPS, download over HTTP, then verify the hash. Software updates like this are a case where all you really need is integrity (I know some people would like confidentiality, but let's be honest, if an attacker sees you download X bytes over HTTPS from apple.com, and the latest apple update is X bytes, you've lost confidentiality already), and integrity can be achieved without sending the file itself over HTTPS.

In fact, this technique maybe preferable -- Apple could have a small number of servers serving update metadata under their direct control (i.e., URL and hash of the update) and then use a 3rd party CDN to distribute the update, reducing bandwidth costs, latency, etc. If the update were served by the CDN directly over HTTPS without the verification step (i.e., all integrity is from HTTPS), then the CDN (or someone who compromises the CDN) could replace the update with a modified version.

Whether or not the duplicate ACKs are something to worry about is largely a separate question. My level of concern would depend on a number of things: are they outbound or inbound ACKs? What are the TTLs? What are the sequence numbers? It's really hard to say, but I suspect duplicate ACKs are far more likely caused by a network misconfiguration somewhere (even if not your network) than by an attacker.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .