Why does iTunes 10.7 try to contact the domain bogusapple.com?

I have noticed this in the Mac App Store aswell. But I haven't noticed that any servers were down.

Earlier today, my Mac restarted with weird kernel messages followed by another reboot. This happened so quickly, I could not tell what was going on. Is this some kind of malware that we caught?

I just blocked an attempt to connect to bogusapple.com too, anyone know what the site is?

Going to www.bogusapple.com in a browser shows a placeholder provided by the registrar. Going to bogusapple.com, however, shows the following:

Hi! You're here because of some feature in OS X Mountain Lion that I'm incredibly curious about.

• No, I didn't hack your computer.
• No, being here does not mean you did something wrong, or that something is broken.
• No, There's no malware on this site, there's not even an image, and I don't set cookies.
• I think Apple "tests the waters" by sending you to bogusapple.com to ensure it fails.
• Foolish idea, because any one can run it, and now I do 🙂

Who am I? No one particularly important.

Does this page's existence make you as curious as this domain did to me? Get in touch with me!

So Apple for whatever reason maybe uses it as a fallback domain, if something goes wrong like it did last night, they redirect whatever is going wrong to that domain. See below for a more lengthly explanation as to how I arrived at this conclusion:

Same issue here. Little Snitch caught it, I denied until quit, seems like everything is working ok so I'm not sure what traffic was affected.

The connection alert popped up when I tried to play a song from the Cloud as I have iTunes Match turned on. Before the song would play I had to agree to new iTunes terms and conditions. I was still able to accept terms and conditions.

I know last night (September 30, 2012) into this morning there was an issue on (at least) iDevices where the ToS popup led to an endless loop where they could not be accepted, maybe this has something to do with it? The interwebs report the issue is fixed as of now.

Also, I was unable to get any music off iTunes Match on my iPhone 4S running 6.0. I would play a song and it would skip to the next and the next and go on doing that until I forced quit. I could watch the album artwork flash on the screen, but nothing would play. Before coming here, I turned off iTunes Match on the iPhone, rebooted, synced a few songs the traditional way from iTunes, then turned iTunes match back on for the iPhone, and now I seem to have no issues.

Also, I have not accepted any new Terms on the iPhone, and I have purchased a song from iTunes on the device as a test.

Back to bogusapple.com , whois seems to show the owner of the domain is shielded by Contact Privacy Inc in Toronto. Ahh, see the first paragraph, which I typed last.

Just tweeted the owner and he purchased it 2 hours ago. I assume that means after he noticed the same thing we did.

That's exactly why I picked up the domain and set up the site 🙂.

Nothing specifically exciting yet, pretty standard visits so far. The only unique thing is attempts to retrieve a 'missing.html' file.

User agents are however a completely different story. Browsers, iTunes (Windows + Mac), Flipboard, a few Twitter apps, etc.

Invariably since public discussion has started here and in a public chat room, most recent visits? The spam bots to a handful of phony URLs.

Awesome - I'm surprised they used a domain like that and not an API for discovering whether DNS was resolving or a certain port were open. At worst, I could see them using something more self-explanitory like:

no-dns.apple.com to test something that never should be in DNS and site-down.apple.com and site-up.apple.com for http port status.

But then again, I'm just in the peanut gallery, eating popcorn on this one.

Jason,

Are you listening on all ports, or just port 80?

Just :80. It's on a shared web host, it was the quickest way to see any traffic occurring. It's a shame I can't adequately log :443 as a result though.

Based off the initial evidence (iTunes and MAS), it sounded like they would be plain HTTP requests. I think I've been mostly right in that regard.

My inclination was to capture User Agents. Obviously that concept generally doesn't exist outside of HTTP. Though now that I think about it, having access to raw payloads would be very interesting to see as well, and just respond to things that are HTTP requests with the current content like I have now. Sounds like a fun undertaking.

Perhaps just a typo by the developers: maybe they meant bogus.apple.com? Easy to miss in testing, and that would be a reasonable DNS test (though still odd from a user experience side).

Jason, it does appear that iTunes is either validating the server key against some expected value, or is bailing after establishing the connection without sending a payload. I redirected bogusapple.com traffic to an arbitrary web server (running SSL) via my hosts file, and used Wireshark to examine the traffic. After the key exchange handshake, iTunes immediately sent FIN,ACK.

iTunes shouldn't be validating the server key against an expected value, given that a (normally) non-existent site won't be providing one 🙂. iTunes likely bailed out due to an SSL (hostname mismatch?) is all. It would do exactly the same when the site fails to respond in time and the connection fails.

This sounds like a check to see what the connectivity status of the network is.

Because they request a (previously) non existing domain and a /missing.html page this sound the software intentionally tries to trigger a failure. This makes me think it's related to wifi login detection. Say you visit a Starbuck, initially they serve you a landing page, even when you request a non-existing domain.

Might be related to the wifi bug fix last week caused by the page the software requested previously accidently returning succesfully ( http://arstechnica.com/apple/2012/09/wifi-connectivity-under-ios-6-temporarily-b roken-by-server-proble/ )

I've been proceeding on the assumption that they intended this request to go to an existing server, and just screwed up, in which case they will be expecting (I assume) a certificate they can validate via PKI. Internally, during development bogusapple.com would refer to a server running in their development environment, so they don't roll out their new features to production ahead of schedule. When they released, someone forgot to update the host name.

I bring this up only because you appeared interested in assessing the payload of the HTTPS requests, which I imagine would only exist if they expected something to respond to the request. If the alternative theory is correct, that this is an attempt to gather diagnostic information, then indeed they would not be expecting any particular result, nor sending any particularly interesting payload.