Mountain Lion introduces a small, yet significant change in how OS X clients communicate with Apple’s Software Update servers.
Mountain Lion clients by default now consult an HTTPS URL to check for updates on Apple’s servers.
This has the implication that you can no longer use DNS trickery with Mountain Lion clients to get them to access your internal SUS instead of Apple’s. Some organizations configured their internal DNS servers to resolve requests to swupdate.apple.com to an internal server.
The appeal of this approach (DNS hijacking) was that you did not need to touch any client machine to get it to use your internal Softwar Update server; any client using your network would “automagically” use your internal Software Update server.
HTTPS connections do certificate verification of the host. Since your internal SUS can’t offer a certificate proving it is Apple’s server (because it’s not!) a Mountain Lion client will refuse to talk to it. (It’s also possible that your internal SUS is not accepting HTTPS connections anyway, but even if you were to turn that on, it would not help.)
HTTPS prevents exactly the sort of DNS impersonation that made this hack work in the first place. Apple has closed that door.
In order to use an internal Software Update server (either Apple’s or Reposado) with Mountain Lion clients, the clients must be explicitly pointed to your internal server via MCX or by setting the preference using:
defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL <internalSUScatalogURL>
Managing OS X 
I had guessed this was why our DNS hack wasn’t working, but it’s nice to have it verified. Thanks!
Couldn’t you create a self-signed certificate for swupdate.apple.com and copy that certificate to the clients? Or sign it with an organisational certificate already installed on your clients?
If you are going to copy something or install something on all your clients, why not just make the proper configuration change? The entire reason people do/did DNS hacking was to avoid having to touch every machine.
Well, indeed the first solution would require that, but the second solution might refer to something already present, but yes, I agree; was just offering alternatives/ideas.
Personally, I have always used the Workgroup Manager Guest Computer to push that setting to workstations.
The potential problem I see with that (I’m still getting up to speed myself) is that 10.8 defaults to only accept App Store and “identified” developers. This means you need to download a signed package, resign software with your Apple developer certificate or change the client setting. But just this week I was able to setup my internal swupd server for my company on 10.8 using http. The trick was the the previous URL of …8088/index.sucatalog won’t work because swupd 10.8 doesn’t setup this file automatically. But it does work with straight http.
Gatekeeper only checks the signing of the downloaded package, not the signing of the https certificate.
If you are using Profile Manager, you already have your own CA that your clients trust, so you could use it to sign the SSL cert. for your DNS hack. But if you use Profile Manager, you could also push the CatalogURL. And that’s more elegant.
I have seen many hacks that work well today cause much pain later on, when other have to deal with it and its not properly documented or documentation lost etc. Imagine someone else taking over Software update Duties 2 years down the road, having to troubleshoot it not knowing you changed the DNS entries for swupdate.apple.com
So: Hacks don’t pay.
Well all the point of doing the DNS hack is to avoid changing the preferences. It’s really useful especially in school environment.
Like when the laptop is on campus, all software update are going directly to the school software update. And as soon as the students leave the school, they can still use Apple software update back home for example.
By setting the preference to use the local SUS, students cannot apply update if they are at home or during holidays.
Well, you could always do as we did and slap a lil app in their Applications folder (signed with your developer ID of course), to allow them to change it back at home.
So in the end there is no way to re-establish the transparent local SUS like we used for years? No chance for DNS hack anymore?
Thanks for any reply!
I have to admit, this makes me sad. I’ve been using a wpad.dat file with polipo to cache Mac OS X updates. Its a shame too, considering that the packages are already signed, they don’t really need SSL while downloading.
> … they don’t really need SSL while downloading
The first thing SUS does is fetch catalog files, which are an unsigned tar ball (*.GZ). The attacker can manipulate the catalog undetected. Its another Apple SECURITY FAILURE.
> … packages are already signed…
The “package” is not signed. Items or elements within the package are signed. That means the package can be tampered and go undetected.
Schneier and Wagner introduced “Semantic Authentication” in 1996 after analyzing SSLv2. Apparently Apple did not get the memo. Its another Apple SECURITY FAILURE.
[…] reason for the error has its root in a change which Apple introduced with OS X 10.8.x, where Macs running 10.8.x and 10.9.x use an HTTPS URL to check for updates on Apple’s […]
[…] reason for the error has its root in a change which Apple introduced with OS X 10.8.x, where Macs running 10.8.x and 10.9.x use an HTTPS URL to check for updates on Apple’s […]