Hacker News new | comments | show | ask | jobs | submit login

This bug was pretty serious. I'd better be extra careful and install and verify this myself.

Oh, good: there's a standalone installer available (http://support.apple.com/kb/DL1726). But the download is served over HTTP. Maybe I can just try the same URL with HTTPS:

  $ curl --head https://support.apple.com/downloads/DL1726/en_US/OSXUpdCombo10.9.2.dmg
  HTTP/1.1 302 Moved Temporarily
  Server: Apache/2.2.24 (Unix)
  Location: http://download.info.apple.com/Mac_OS_X/031-3279.20140225.Zzasf/OSXUpdCombo10.9.2.dmg
Nope. Well, at least I can verify the SHA1 sum displayed on the download page. Wait, no, that was served over HTTP, too.

Okay, I'll follow Apple's instructions for checking the certificate fingerprint in the installer (http://support.apple.com/kb/ht5044). But that page (Last modified November 2011) displays a different fingerprint (9C864771 vs FA02790F)...and that fingerprint was also served over HTTP.

Gives up and opens the App Store.

The packages themselves are signed: Mount the .dmg file and use pkgutil --check-signature /path/to/Installer.pkg to check whether the package is signed by a valid CA (if you want to be totally sure, do this check on a machine running 10.8 or earlier)

FWIW, I did this for the combo update. The SHA1 checksum on the Apple page, c06a63982b522e43997a05cedc04b0bdb1a10207, matches the file, and pkgutil reports

   Package "OSXUpdCombo10.9.2.pkg":

   Status: signed Apple Software

   Certificate Chain:
    1. Software Update
       SHA1 fingerprint: 1E 34 E3 91 C6 44 37 DD 24 BE 57 B1 66 7B 2F DA 09 76 E1 FD

    2. Apple Software Update Certification Authority
       SHA1 fingerprint: FA 02 79 0F CE 9D 93 00 89 C8 C2 51 0B BC 50 B4 85 8E 6F BF

    3. Apple Root CA
       SHA1 fingerprint: 61 1E 5B 66 2C 59 3A 08 FF 58 D1 4A E2 24 52 D1 98 DF 6C 60

This is all pointless handwaving; the update package itself is signed and will not install if tampered with, regardless of TLS certs used to download it.

TLS is not used to authenticate the update.

Ah, right. That makes sense. If only it was mentioned on the download page!

Meh, just admit you didn't realise how packages are signed and move on. TLS shouldn't and cannot be used to sign installation packages. After all, TLS stands for _Transport Layer_ Security...

He followed some pretty logical steps and made a fair enough point, there's no reason for you to be a douche about it.

Well you have the right to feel offended, but he really didn't "follow logical steps and make a fair enough point" as his idea was completely wrong when it comes to signing installation packages.

Well. In a way it's mentioned here: http://support.apple.com/kb/ht5290

Yes. That's the marketing page explaining how Gatekeeper works, but yes, in the end it's a feature of Gatekeeper that makes it harder for you to open unsigned packages and impossible to open packages with a broken signature.

So even when you don't know about pkgutil (most people don't), Gatekeeper will still help you.

In addition to pillf's suggestion:

  1. Use linux/fbsd/obsd/win box to download update.
  2. Verify authenticity of cert/sha1
  3. scp dmg / copy to USB drive
  4. Apply update and move on.

"Mom, First use linux/fbsd/obsd/win box to download update. Next verify authenticity of cert/sha1. Then just scp dmg / copy to USB drive, apply update and move on."

If you're 13, add "duh" at the end.

That is a cute response. The only problem is that you are substituting "mom" for OP.

Did the mother of your thirteen year old preface her question with "I already tried to use curl but then I realized that would not work. Then I thought I could verify the SHA1 but I realized I was obtaining the sha1 value over an insecure channel."?

Steady now, that's my mother you're talking about...

I agree that context matters. That's why statistically the proposed solution isn't a solution. It doesn't really work in a way that address the serious issue because the serious issue is the sheer magnitude of the number of compromised systems.

To put it another way, if you have a Linux or Windows or BSD box why keep a potentially deeply compromised OSX installation around at all. The patch isn't going to unpwn a pwnd box. The hoops might insure the patch isn't compromised but in terms of system security the horse is out of the barn and all the way to the glue factory.

The only case where jumping through those hoops makes a difference is in the second best case. And that's statistically equivalent to the best case and preparing for the best case in regard to security goes by the name of "wishful thinking."

My mom would go ahead and do it.

Seems ironic that of all the patches that don't get served over SSL, the "SSL is meaningless" bug is the one where you'd point out that SSL should be available :P

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact